From 5ea943a5e789222472e45864e119cf786498bfcd Mon Sep 17 00:00:00 2001 From: Rodrigo Arias Mallo Date: Mon, 1 Jan 2024 23:40:52 +0100 Subject: Import original dillo.org website into old/ --- old/oldmail/199912.txt | 2015 ++++++++++++++++++ old/oldmail/200001.txt | 313 +++ old/oldmail/200002.txt | 295 +++ old/oldmail/200003.txt | 200 ++ old/oldmail/200004.txt | 906 ++++++++ old/oldmail/200005.txt | 388 ++++ old/oldmail/200006.txt | 309 +++ old/oldmail/200007.txt | 1378 +++++++++++++ old/oldmail/200008.txt | 3527 ++++++++++++++++++++++++++++++++ old/oldmail/200009.txt | 2365 +++++++++++++++++++++ old/oldmail/200010.txt | 3767 ++++++++++++++++++++++++++++++++++ old/oldmail/200011.txt | 2106 +++++++++++++++++++ old/oldmail/200012.txt | 2938 ++++++++++++++++++++++++++ old/oldmail/200101.txt | 311 +++ old/oldmail/200102.txt | 1380 +++++++++++++ old/oldmail/200103.txt | 1492 ++++++++++++++ old/oldmail/200104.txt | 1303 ++++++++++++ old/oldmail/200105.txt | 2469 ++++++++++++++++++++++ old/oldmail/200106.txt | 1433 +++++++++++++ old/oldmail/200107.txt | 593 ++++++ old/oldmail/200108.txt | 2926 ++++++++++++++++++++++++++ old/oldmail/200109.txt | 2932 ++++++++++++++++++++++++++ old/oldmail/200110.txt | 3823 ++++++++++++++++++++++++++++++++++ old/oldmail/200111.txt | 3639 +++++++++++++++++++++++++++++++++ old/oldmail/200112.txt | 3635 +++++++++++++++++++++++++++++++++ old/oldmail/200201.txt | 3654 +++++++++++++++++++++++++++++++++ old/oldmail/200202.txt | 5334 ++++++++++++++++++++++++++++++++++++++++++++++++ old/oldmail/200203.txt | 3136 ++++++++++++++++++++++++++++ old/oldmail/200204.txt | 4243 ++++++++++++++++++++++++++++++++++++++ old/oldmail/200205.txt | 4676 ++++++++++++++++++++++++++++++++++++++++++ old/oldmail/200206.txt | 4972 ++++++++++++++++++++++++++++++++++++++++++++ old/oldmail/200207.txt | 1987 ++++++++++++++++++ old/oldmail/200208.txt | 1858 +++++++++++++++++ old/oldmail/200209.txt | 1134 ++++++++++ old/oldmail/200210.txt | 1951 ++++++++++++++++++ old/oldmail/200211.txt | 1659 +++++++++++++++ old/oldmail/200212.txt | 769 +++++++ old/oldmail/index.html | 49 + 38 files changed, 81865 insertions(+) create mode 100644 old/oldmail/199912.txt create mode 100644 old/oldmail/200001.txt create mode 100644 old/oldmail/200002.txt create mode 100644 old/oldmail/200003.txt create mode 100644 old/oldmail/200004.txt create mode 100644 old/oldmail/200005.txt create mode 100644 old/oldmail/200006.txt create mode 100644 old/oldmail/200007.txt create mode 100644 old/oldmail/200008.txt create mode 100644 old/oldmail/200009.txt create mode 100644 old/oldmail/200010.txt create mode 100644 old/oldmail/200011.txt create mode 100644 old/oldmail/200012.txt create mode 100644 old/oldmail/200101.txt create mode 100644 old/oldmail/200102.txt create mode 100644 old/oldmail/200103.txt create mode 100644 old/oldmail/200104.txt create mode 100644 old/oldmail/200105.txt create mode 100644 old/oldmail/200106.txt create mode 100644 old/oldmail/200107.txt create mode 100644 old/oldmail/200108.txt create mode 100644 old/oldmail/200109.txt create mode 100644 old/oldmail/200110.txt create mode 100644 old/oldmail/200111.txt create mode 100644 old/oldmail/200112.txt create mode 100644 old/oldmail/200201.txt create mode 100644 old/oldmail/200202.txt create mode 100644 old/oldmail/200203.txt create mode 100644 old/oldmail/200204.txt create mode 100644 old/oldmail/200205.txt create mode 100644 old/oldmail/200206.txt create mode 100644 old/oldmail/200207.txt create mode 100644 old/oldmail/200208.txt create mode 100644 old/oldmail/200209.txt create mode 100644 old/oldmail/200210.txt create mode 100644 old/oldmail/200211.txt create mode 100644 old/oldmail/200212.txt create mode 100644 old/oldmail/index.html (limited to 'old/oldmail') diff --git a/old/oldmail/199912.txt b/old/oldmail/199912.txt new file mode 100644 index 0000000..3e029d0 --- /dev/null +++ b/old/oldmail/199912.txt @@ -0,0 +1,2015 @@ +[Dillo-dev]Home page (ASCII version) + +From: Jorge Arellano Cid - 1999-12-31 13:27 + +============================================================================== +Here's the new home page: +============================================================================== + + +The Dillo Web Browser +_________________________________________________________________ + +Welcome to Dillo project! + +What's Dillo? + +Dillo is a web browser project based upon gzilla-0.2.2 and +Armadillo-0.3.10. +It aims to be a multiplataform browser alternative that's stable, +developer-friendly, usable, fast, and extensible (Dillo is a free-SW +project in the terms of the GNU public license). +_________________________________________________________________ + +Fast links: + +* Achieved goals +* Naming&Coding design +* Bug-track engine +* Authors +_________________________________________________________________ + +News: + +Dec 30, 1999 + +Updated the web site, wrote new patching directions, updated the +bug-track engine, incorporated several patches, and currently planning +a new tarball release. + +Dec 18, 1999 + +Naming&Coding, Stage 2, is finished, completely!!! +_________________________________________________________________ + +Current goals + +Our primary concerns by now are (Dec 30, 1999): +* Fix and stabilize Dillo to be at least as stable as gzilla-0.2.2, +but faster. (this is our main and first goal by now) +* Fix the rendering bugs that affect GIF and JPG files (Those that +were working good in gzilla-0.2.2). +* Document Dillo internals within the source (every function). + +Future Goals (these may change in the future) +* Make '#' anchors work. (The rendering part of it) Currently those +anchors leave you at page's top +* Incorporate the FTP plugin (I tested it, it works but I just need +to put it there) +* Define a simple plugin API (stdout based) +* Begin designning a dynamic loadable plugin scheme +* Fix and improve rendering +* Begin working on TABLE support! + +That's enough work for now! +_________________________________________________________________ + +Developer info + +Brief Program Overview + +Dillo is a browser purely written in C; that helps to make it very +fast and produces a smaller binary file than what would be achieved +with C++. The trade off is that inheritance gets more complex cause it +must be implemented with C code. That's a bit scary at the very +beginning, but is not as bad at it seems. + +Dillo internals are not of a simple nature. A Web browser is an +inherently complex application. Just think of every thing that needs +to be coordinated to get the job done. And at the very same time! + +Dillo's main libraries are gtk+ (gimp tool kit) for widgets and glib +for almost everything else (as memory management). So, if you happen +to be developing new code, please try to find what glib has to offer +you, amd use it. Needless to say, you must use g_malloc, g_free, +g_realloc and friends. + +Dillo's SW-techniques include threads, callbacks, signal driven IO +(input/output), a bytesink abstraction layer and an IO engine that +cares file descriptor activity (including sockets). Ah, there's also a +widget abstraction layer that serves as an internal ADT (abstract data +type) to gtk+; It's called Dillo widget (Dw_ within function names). + +I'll try to document those later. Please be patient. + +Now you know what you'll face when digging inside the code. + +Patching + +Patching is very welcome. Specially if the patched bug comes from the +bug-track engine. But beware, only high quality patches will be +accepted. +Dillo is following an evolving software-model where every new version +of it, should be better than the former; there's no place for unstable +releases! + +So, if you want to submit a patch, please make sure: + +It passes a 30 minutes stress test +A stress test is a testing situation where you put the newly +implemented routines under heavy workload (more than what's +expected under normal circumstances). + +It passes your own custom testing functions +An alternative to the former point. If the stress test is hard +to implement, or the new functionality is better covered with +this kind of test, chose this way! + +It follows Dillo's Naming&Coding design +Every patch must strictly follow our coding standar. Just to +keep our code clean, and to simplify the patch-reviewing task. + +It fixes the problem and doesn't cover the symptoms. +Sometimes the problem itself lies in a deeper layer; take your +time, investigate and fix it the right way. + +You submit your patches following a "one bug, one patch" scheme. +Don't submit a huge monolithic patch that fixes several things. +Split it into smaller patches, one for each bug. + +You strive for clean code, not for hacks. +Although it's very cool to write fancy solutions, they are +harder to understand and to maintain; please avoid them. + +You let others know what you're doing +Don't do silent patching; use the bug-track engine, make a bug +report and update your progress regularly. Ask for help if you +need it. + +Contributing + +If you're planning to contribute and stay with the project as part of +the development staff, please subscribe to the mailing list, and email +me your expertise areas and interests; keep reviewing the bug-track +engine and the Web site, participate, and have fun! + +The bug-track engine + +It explains it's purpose by itself, go and take a look at it at: + +http://academico.inf.utfsm.cl:81/~jcid/Dillo/Dbugtrack.html + +USE IT! + + +======================================================================== + +Jorge.- + + + +[Dillo-dev]Server is down + +From: Jorge Arellano Cid - 1999-12-31 13:12 + +Hello there, + + +I had just finished updating the website, the bug-track +engine, the patching process directives and several other things, +and when trying to commit them, I noticed that the Web server was +turned down... But it was worst, the whole university net was +turned down, on purpose, without a notice nor a warning: they +turned it off just like that... + +I cant express how ashamed I feel; all I can say is that I +know people there that had helped us a lot (with servers, advice +and the like) and this 'decision' was on someone else's hands... +I thank God for having this mailing list running on another +machine (I was offered a mailing list...), and to have a +communication channel with you. + +As I wrote before, they didn't warn anyone, so I don't know +when it will be up; maybe January 3... If this is not the case, +I'll start moving the site to so....net and start working +from there. + +Please receive my apologies, and let's try to coordinate the +project with the mailing list these days. + +BTW, I was trying to make a new tarball release before Y2K, +and now it will have to wait; personally I'll use this time to +continue digging deep to the roots of the image rendering bug. + + +sincerely +Jorge.- + + + +[Dillo-dev]bug #23 + +From: Jorge Arellano Cid - 1999-12-30 13:49 + +With regard to bug #23, I sent this lines to Luca: + + +----------------------------------------------------------------- +With regard to your ideas request for the preferences menu, I +have several, but most of them are not implemented yet, so you'll +have to think of it, as a module that will be heavily changing +over time. + +* User selected preferences must be saved to a file +'preferences.rc' (readable config) inside .dillo/ directory. +* Actually, there's code inside the new tarball that +implements a gentle background-alternative to WHITE. (I always +thought it must be in the preferences menu :) +* The new progress bar code lets choices on fonts and colors +(to be considered in the near future). + +Not yet implemented, but desirable: + +* Text font (and size) preference +* Load images (YES/NO) Def: YES +* Use decompressed image cache (YES/NO) Def: YES +* Save preferences on exit (YES/NO) Def: NO +* Save preferences functionality + + +I know this is mostly 'vaporware' and probably will be easier +to handle and implement in the future; you choose! +----------------------------------------------------------------- + + +Jorge.- + + + +[Dillo-dev]News (lots) + +From: Jorge Arellano Cid - 1999-12-24 01:48 + +Hi! + + +Although I haven't wrote much to the list, my work has been +divided into several areas; some quite interesting! + +Let's start: + +* There are several changes and patches already integrated to +the code; current changelog looks like this: + + +dillo-0.0.4.tar.gz + +- Added more comments to the source +- Removed dw_test +- Implemented rendering for
tags +- Implemented background colors +- Changed some ADTs to glib +- Added PNG image format support +- Fixed a compilation crash that affected RedHat 6.1 systems + + +* I still have some (very interesting) patches in my queue and +when they make their way into the code, you'll notice the BIG +difference. (Luca made neat changes to the UI and he also +implemented the 'View source' functionallity among others! You'll +find that detailed in the final Changelog.) + +* I've been patching too. Most of it can be tracked at the +engine. + +* There're still more patches to include!!! + +* The Web server was behaving erratically so I had to get to +it (lots of time). Now it's working better and I hope that to +last. If you experience problems with it, please let me know. + +* I've been to the University were I studied, and they granted +me access to several machines (that's why I had the chance to +test with redhat 6.1 among others). Several things are happening, +and all I can tell you by now is: cross your fingers! Excellent +news could spring from that. + +* While testing dillo on Redhat 6.1 (glibc2) I found critical +races (problems). That's good and bad: good cause now I know the +obscure cause of some erratic behavior, and bad, cause it's not +simple. + +* What else? I continued testing, and compared gzilla-0.2.2 +select-based IO (polling) routines against SIGIO (introduced by +Randall Maas into armadillo), and ... guess what? + +I'll have to design a more detailed test cause, with that +kernel, the former method was significatively faster than the new +one! The test was as simple as averaging a few page loads from an +specific address (freshmeat) with both browsers, gzilla-0.2.2 and +dillo-0.0.3. + +Once again, that's good and bad :) + +Good: ++ If the test is right (I mean, it remains TRUE most of +the time), we'll end up with a browser that's faster than what we +actually have (by changing the IO engine). ++ The internal implementation is very much simpler with +the former method, and that leads to code thats much easier to +understand and maintain. + +Bad: ++ (think about it...) + +* I also focused my efforts on project security concerns. +There'll be new plans, most of them introduced next year... BTW, +please bear in mind that current project status is not secret, +but private (I know this is a complicated area to discuss, but +please think about how many browser projects you knew, and after +that, focus on what we have here...) + +* CVS stuff: I want to start working with it. Just to keep +track of project history, and to keep a detailed Changelog of it. +I'm curently designing a patching submition scheme to help us +keep it clear and useful (not the highest priority though). + + +Finally, I want to thank everyone here, just as accurately as +my english allows me, for the excellent spirit this project has +shown in this first month of work. +Let's keep it that way! + +I also hope it not to be too late, to wish you an excellent +Christmas, and a joyfull new year celebration! + + +sincerely +Jorge.- + + + +[Dillo-dev]News + +From: Jorge Arellano Cid - 1999-12-21 23:42 + +Hi there! + + +The work here has been up to full capacity! + +* The patch that removes gzw_test is applied (thanks Sammy) +* The Background feature patch also made its way into the code! +(thanks James and Luca) +* Luca sent me some patches more that I'll start working on... +* I have also been working out the code and made some fixes. + + + +I know the Web server is working awfully slow. I'll try to get +to that machine tomorrow and see what's happenning. Please be patient. + + +best regards +Jorge.- + + + +Re: [Dillo-dev]remove test gzw ? + +From: Rota Luca - 1999-12-21 20:00 + +On Mon, 20 Dec 1999, nightstalker wrote: + +> should i get rid of the 'test gzw' feature or not ? + +Yes! +Well, I think so :) + +Ciao, +Luca + + + +[Dillo-dev]remove test gzw ? + +From: nightstalker - 1999-12-20 19:25 + +i was just cleaning up some stuff from commands.c .. and i was wondering +.. + +should i get rid of the 'test gzw' feature or not ? + +sammy. + +ps: answer as soon as you can please :) + + + +Re: [Dillo-dev]how to use ddd or gdb with dillo + +From: Jorge Arellano Cid - 1999-12-20 00:27 + +Sammy, + +> how can i use ddd or gdb with dillo ? i think it had to do with +> uncommenting two lines ? + +You can debug it without any changes using local files but, if +you need to debug it, using the dns stuff, then go to 'dns.c', +line 42, and comment it out. That's all! + + +Thanks for commiting yourself to fix some bugs. + + +Sincerely +Jorge.- + + + +[Dillo-dev]how to use ddd or gdb with dillo + +From: nightstalker - 1999-12-19 22:28 + +how can i use ddd or gdb with dillo ? i think it had to do with +uncommenting two lines ? + +sammy. + + + +[Dillo-dev]announce dillo to the public ? + +From: nightstalker - 1999-12-19 22:18 + +hi all, + + +i think this is a time when we can announce the project to the public +... +(for example via freshmeat) + +now that the name changing / indenting has ended, i think we have a good + +basis for further development ! the name change actually worked, +something +we never achieved with gzilla/armadillo :) + +sammy. + + + +[Dillo-dev]Update + +From: Jorge Arellano Cid - 1999-12-18 22:23 + +Hello everyone! + +I updated the website once more. Visit it thoroughly! +BTW: The bug-track engine has new load :) + +Good luck! +Jorge.- + + + +[Dillo-dev]Another tarball release!!! + +From: Jorge Arellano Cid - 1999-12-18 18:37 + +Hi! + +dillo-0.0.3.tar.gz is ready at the web site! +(following patches must be against this version) + +It features several improvements; read them in the ChangeLog +inside the tarball. This will be our code base for bug fixing. + +Finally, our house is clean and we can start removing bugs from +Dillo. I'll flood the bug-track engine soon... + + +Jorge.- + + +Pd: I'm very happy to be at this point; as fast as we did. + + + +Re: [Dillo-dev]Stage two + +From: Jorge Arellano Cid - 1999-12-18 10:30 + +Daniel, + +> I'll do it. I think I have more access time to computers from now on. +> Perhaps (holds breath) I might even have Linux up and running... + +well, I already did it but... + +> Just give me the details and what you want me to do. + +Would you mind making some changes in the future? i.e. I send +you the ASCII with the contents and you email me back the html +pages? + +> Jorge Arellano Cid escribió: +> ... + +¡Con acento y todo! +Felicitaciones. + + +Gracias +Jorge.- + + + +[Dillo-dev]**** Stage 2 **** + +From: Jorge Arellano Cid - 1999-12-18 01:46 + +Hi there! + +It seems that Luca has done 90% of the Stage 2 work with a +couple of nice scripts!!! + +I run them and found minor problems that I want to polish +before releasing a new tarball!!! + +The good new is that you won't have to do anything, stage 2 is +almost complete! + +Some files didn't pass the object files test, so I'll check +those tomorrow, fix a couple more things and voila, new tarball. +From then and on we'll focus on BUG fixing. + +These ARE good news! + +Thank you very much Luca. + +Jorge.- + + + +[Dillo-dev]*** Stage 2 *** + +From: Jorge Arellano Cid - 1999-12-18 01:25 + +Hi there! + +It seems that Luca has done 90% of the Stage 2 work with a +couple of nice scripts!!! + +I run them and found minor problems that I want to polish +before releasing a new tarball!!! + +The good new is that you won't have to do anything, stage 2 is +almost complete! + +Some files didn't pass the object files test, so I'll check +those tomorrow, fix a couple more things and voila, new tarball. +From then and on we'll focus on BUG fixing. + +These ARE good news! + +Thank you very much Luca. + +Jorge.- + + +Pd: This message comes from another server cause mailtag is down. + + + +Re: [Dillo-dev]Stage two + +From: Daniel Moore - 1999-12-17 21:30 + +I'll do it. I think I have more access time to computers from now on. +Perhaps (holds breath) I might even have Linux up and running... + +Just give me the details and what you want me to do. + +Cheers, +Daniel. + +Jorge Arellano Cid escribió: + +> Hi! +> +> Good news are: +> +> * I'm planning to release the new tarball today. +> * Luca has plenty of patches +> * The tarball has many many changes (you'll see) +> * I have stage two directives written +> (just need to put them on the web site) +> +> Bad news are: +> +> * Jarrod has no time now to arrange the web site. +> * I'll have to do that (delay root...) +> +> Jorge.- +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]Updated web site + +From: Jorge Arellano Cid - 1999-12-17 20:37 + +Hello! + +Finally, the new Web site is up and running. +Go take a look at it; several things changed. + +I wrote a bit of everything there :) + + +Jorge.- + + + +[Dillo-dev]New tarball release + +From: Jorge Arellano Cid - 1999-12-17 17:42 + +Hi! + +Is official now, there's a new tarball: dillo-0.0.2.tar.gz +Grab it from the site! + +Luca tested it and it works fine... +(dillo-0.0.2.tar.gz is exactly the same as d2.tar.gz) + +enjoy +Jorge.- + + +Pd: Feedback? + + + +Re: [Dillo-dev]New tarball test oportunity :) + +From: Rota Luca - 1999-12-17 16:42 + +On Fri, 17 Dec 1999, Jorge Arellano Cid wrote: + +> I really hate a tarball that doesn't compile, so the first one +> to answer this mail, will be replied with the alfa tarball URL, +> and I'll wait online for him to reply me the results. OK? + +d2.tar.gz compile fine and work fine on my box. +I get only a pair of warning (but they're in the previous tarball, too). + +Ciao, +Luca + + + +[Dillo-dev]tarball alpha test + +From: Jorge Arellano Cid - 1999-12-17 14:26 + +Hi! + + +Well, I waited online, but nothing happened.. +The alpha tarball is name d2.tar.gz. +I'll check your answers ASAP; got to go out now.... + + +Jorge.- + + + +[Dillo-dev]New tarball test oportunity :) + +From: Jorge Arellano Cid - 1999-12-17 13:00 + +Hi! + +I just finished the new tarball. We're only one step aside +from dillo-0.0.2 release: the alfa test. + +I really hate a tarball that doesn't compile, so the first one +to answer this mail, will be replied with the alfa tarball URL, +and I'll wait online for him to reply me the results. OK? + +(Yes, I tested it thoroughly here, but it always seems to run +perfect on the packager's machine...) + +I'll be right here! +(updating the web site) + + +Jorge.- + + + +[Dillo-dev]Stage two + +From: Jorge Arellano Cid - 1999-12-17 10:23 + +Hi! + + +Good news are: + +* I'm planning to release the new tarball today. +* Luca has plenty of patches +* The tarball has many many changes (you'll see) +* I have stage two directives written +(just need to put them on the web site) + +Bad news are: + +* Jarrod has no time now to arrange the web site. +* I'll have to do that (delay root...) + + +Jorge.- + + + +[Dillo-dev]Stage two + +From: Jorge Arellano Cid - 1999-12-16 00:08 + +Hi! + + +Jarrod is arranging the web site now, and I'm setting the +framework to start with stage two; I have to finish the tarball +too... I hope it to be ready in a couple of days. + +James: I was talking about the patch that you described +writing: +"All this patch does is fix the bug where hitting reload before +loading any pages crashes the browser. It also adds some +consistency to initialization of dillo objects." + + +Sammy: I referred the patch that: +"changes: bookmarks add shortcut is now +changed gzilla menu to file menu (heh) +changed help - gzilla home and gzilla manual to +dillo home/manual :) +reindented source +made the name changes for the functions : a_Menu_ +etc ..." + +if you have an actualized version of it, GOOD! :-) + + + +Jorge.- + + + +Re: [Dillo-dev]News + +From: nightstalker - 1999-12-15 17:46 + +Jorge Arellano Cid wrote: + +> Hello everyone! +> + +hi :) + +> +> The big menu patch from sammy (45 Kb) will remain queued until +> stage two completes. I hope stage two effort not to take more +> than one week. +> + +be careful when applying that .. it also has a .h file that is changed +.. (because one of the +a_Menu things should be dumped from .h and changed to Menu... ) + +anyways, the patch is so big cause i also did reindenting in that one. +i didn't make a lot of changes to the code .. + + + +[Dillo-dev]News + +From: Jorge Arellano Cid - 1999-12-15 12:14 + +Hello everyone! + + +Today I'm very happy and maybe in a couple of weeks I'll have +very good news for the project (even more)... Hold on, if it +happens, I tell you! + +Now I have some work to do but, after that, I'll go to the Web +site console and make some updating there; the stage one of the +naming&coding effort is about to finish, and now is time to set +a framework for stage two. + +I'd be very happy to have a Web site maintainer (or +volunteer), someone that I could send ASCII text with the Web +site contents, and from whom I can get back the HTML (well, +there's some site arranging and design work involved). That way +it would be much easier for me to keep fresh contents there... +But if you're able to do patching or BUX fixing work, I'd +rather prefer you to work on those areas! + +Stage two will be cleanning time (discussed on the list) and +time for fixing (improving and wiping) all those rough edges you +had taken notes on, while working out the sources. + +For instance, when facing the IO module, I found an incredible +mess there! It was so impressive that I decided to block every +single source with my name at the progress-track-monitor, just to +work it out heavily; you'll see what I did in the next Dillo +tarball. + +The same happened when a got to the URL module; but this time +it didn't take me by surprise. BTW I was led there by a BUG! (one +more). And it was cloaked with some fancy stuff! There were +function definitions within the header files (__inline__); that +makes them invisible to a debugger... + +So I decided to rearrange the whole thing. Once I was ready +with that, bug hunting was a pleasure! Thanks to you all!!! + +I'll try to release the tarball for stage two as soon as +possible. It'll include several improvements, as the ones I +described before, plus some compile time warnings fixes, updated +automake stuff, some other bugs fixed, indented code, +more documentation within the source, some patching I have queued +(from James). + +The big menu patch from sammy (45 Kb) will remain queued until +stage two completes. I hope stage two effort not to take more +than one week. + + +After stage two succeeds, I'll try to start working with the +CVS repository (don't worry, you'll always have a tarball +alternative). + + +Best regards +Jorge.- + + + +Re: [Dillo-dev]#ifdef USE_GZW + +From: - 1999-12-14 22:18 + +We should definitely get rid of these #ifdefs. They were probably +useful when the gzw module was under development, but now it simply +adds more bytes to the source tree. + +-James McCollough + + + +Re: [Dillo-dev]#ifdef USE_GZW + +From: Jorge Arellano Cid - 1999-12-14 22:13 + +Hello! + + +On Tue, 14 Dec 1999, Rota Luca wrote: + +> +> Hi, +> +> I notice that in some files (gzilla{html,plain,web}) there is often the +> code: +> +> #ifdef USE_GZW +> gzw_function(); +> #else +> gtk_function(); +> #endif +> +> Maybe, we could keep the gzw version only, to make the code more readable. +> What do you think about it? + +I think just as you and Sammy, let's wipe that at the second stage! + +Jorge.- + + + +Re: [Dillo-dev]#ifdef USE_GZW + +From: nightstalker - 1999-12-14 19:00 + +Rota Luca wrote: + +> Hi, +> +> I notice that in some files (gzilla{html,plain,web}) there is often the +> code: +> +> #ifdef USE_GZW +> gzw_function(); +> #else +> gtk_function(); +> #endif +> +> Maybe, we could keep the gzw version only, to make the code more readable. +> What do you think about it? +> +> Ciao, +> Luca +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +yep, i think we should keep only one of those ... it makes the source more +readable, +and we don't have to support old stuff we won't use anymore :) + +i found this too in some files (this had to do with supporting gtk 1.1) + +sammy. + + + +[Dillo-dev]#ifdef USE_GZW + +From: Rota Luca - 1999-12-14 18:12 + +Hi, + +I notice that in some files (gzilla{html,plain,web}) there is often the +code: + +#ifdef USE_GZW +gzw_function(); +#else +gtk_function(); +#endif + +Maybe, we could keep the gzw version only, to make the code more readable. +What do you think about it? + +Ciao, +Luca + + + +Re: [Dillo-dev]I am in doubt what to do! + +From: Rota Luca - 1999-12-12 21:44 + +On Sat, 11 Dec 1999, Jorge Arellano Cid wrote: + +> > 1. a_gtk_Dw_view_new +> > 2. a_Dw_gtk_view_new +> > 3. a_Dw_view_new +> > Which do you want? + +> Number 2. + +OK!! I like it, too. + +> Pd: Haven't seen your vote on braces placement yet! + +I prefer: + +if( x == y ) +{ +x++; +y--; +} +else +{ +x--; +y++; +} + +But it's not so important for me :). + +Ciao, +Luca + + + +Re: [Dillo-dev]Re: reindenting + +From: Jorge Arellano Cid - 1999-12-12 13:06 + +Hi, + +Thank you very much for answering Jarrod's email Sammy. +I'll just add a bit to it... + + +> > Jarrod +> Sammy +Me + + +> > I've got a little (Very little) experience in +> > C++, but let me tell you what I would like to see.. +> > could someone do some sort of heavy commenting on the +> > code? + +Have you been there? +The code is commented, not heavily, but up to a good amount +IMHO. Comments aim to unveil the algorithms, or the internals, +not to explain every single detail... + +Why? + +Because programming expertise is an scarce resource, and +solid programming expertise is even more rare, so when a project +happens to count with one of those star-developers, the trade off +is to sacrifice documentation for highly-valued SW. +I'm not putting this to black or white, please don't get me +wrong; it IS a trade off. + + + +> > Or at least do a cflow with a quick +> > description? I understand C a bit, but I need to see +> > some type of roadmap, and "read the archives" is a bit +> > too vague.. + +I'd very much like to see a quick description too, so I tried +to put such an introduction at the web site. I know it was +appreciated cause I can feel a strong collaborative spirit within +this project, and I'm very delighted with that; the efforts this +guys are putting in are not unnoticed by me, the work is tough +and their commitment has been generous to the bone. + +Have you wondered why the naming&coding change effort is +taking place? + +Please, be fair on us and don't blame we put you to "read the +archives". + + +> > I know it seems like a lot, but if I'm +> > ever going to help on the coding end (or if any one +> > else is, for that matter) we kinda need to know what's +> > going on.. +> +> you are right ! Dillo is a BIG program and you need to see +> some kind of flow in the source. i don't know a lot about +> the internals of Dillo yet too :(. + +Knowing the whole functionning of Dillo is hard even for a +core developer. And maybe I'm the one that has been more +thoroughly to the code at this point, so I designed the +naming&coding style, layer abstractions, changing algorithm, +progress tracker and I'm also doing the patch integration task... + +Once we succeed with this, it will be *very* much easier for +everyone to step into the code and to find out what's going on +there, and then, based on individual specific-areas expertise +we'll get to document it. + +But that will be after bug chasing, cause that's the highest +priority (stability), and with the extra knowledge gained from +that stage, the documentation will be more clean, accurate and +pertinent. + + +> i was thinking about +> making some kind of overview that lists every module and +> every function together with what it is supposed to do/does) +> this way we can also try to avoid reimplementing thins like +> lists etc ... and: if you find a bug in a function, you can easily +> lookup which functions performs a similar task to see if the +> bug is there too ... + +Sammy is right, that's the idea. +(although it needs polishing work) + + + +Ok, that's what I needed to say about that. Please don't get +distracted with this and let's continue working on the naming +effort. We still have a lot of work to do finishing the first +stage. + +Whe we get to the second stage (remember the notes I asked +you to take when reviewing the modules), and those new changes +are integrated, it will be celebration time! + +It took a long time to write this answer, and I have plenty +of patches waiting at my queue, but I thought this information +about near-future-plans, would be very useful to us all. + + +OK, now I'll get back to work those patches in... + + +Sincerely +Jorge.- + + +Pd: + +> i always use braces, even for one line of code ... + +OK Sammy, you convinced me, I'll try to add the braces. + + +Pd2: + +> > Also.. one other odd thing.. Dillo does not like +> > glibc2.1 systems. I recall there being some sorta +> > manual fix for gzilla, and I know it'd work on my +> > system.. but I can't recall WHAT that fix was. It +> > involved (If I recall correctly) something with the +> > LDL. Anyone manage to save that? + +Please let us know what compile time errors you got. +I know it works ok with glibc2 systems but extra info is +welcomed. + +> i don't know about this one ...something i wanted to add : +> i tried out the new tarball today (dillo-0.0.1) and it +> compiled fine again on my system (with the 0.0.0 i had to +> type make inside the src/ dir .. make would fail in the +> dillo-0.0.0 dir (due to a configure it did). i'm happy this is +> fixed :) + +I made the autoheader, autoconf, automake stuff again, I hope +that was the fixing root :-) + + + +[Dillo-dev]extended cvs explanation + +From: - 1999-12-11 20:41 + +Here's an outline as to how to use dillo's CVS repository: + +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + +Anonymous CVS Access + +This project's SourceForge CVS repository can be checked out through +anonymous (pserver) CVS with the following instruction set. When prompted +for a password for anonymous, simply press the Enter key. + +set the environment variable CVSROOT to :pserver:anonymous@cv...:/cvsroot/dillo + +then execute: + +$ cvs login +$ cvs checkout dillo + +this will create a directory in the current directory called dillo with +a duplicate of the source in the repository. + +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + +Developer CVS Access via SSH + +***NOTE: this is only for Jorge right now + +Only project developers can access the CVS tree via this method. SSH1 +must be installed on your client machine. Substitute username with the +proper values. Enter your site password when prompted. + +set the environment variable CVS_RSH to ssh and the CVSROOT variable to +username@cv...:/cvsroot/dillo + +first, execute: +$ cvs checkout dillo + +to have a copy in sync with the CVS server. the apply your patches to +your local 'dillo' directory that was created with the checkout +command. Once you are comfortable with the changes, and they have +been tested, update the repository to reflect your changes with this +command: + +$ cvs commit dillo + +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + +Browse the CVS Tree + +Browsing the CVS tree gives you a great view into the current status of +this project's code. You may also view the complete histories of any +file in the repository. +* http://cvs.so....net/cgi-bin/cvsweb.cgi?cvsroot=dillo + + + +Re: [Dillo-dev]Re: reindenting + +From: nightstalker - 1999-12-11 17:31 + +Jarrod Henry wrote: + +> Granted, I am VERY new to C. In fact I doubt I could +> understand coding at all on this project, I'm just +> trying to help in whatever meager ways I can. I've + +you can help in a lot of ways ! for example the name changing +we are doing at the moment. you don't need a lot of c +experience to do that. Some bugs will also be somewhat +easy stuff to do (for example the menu changes i did once, and +the UI things). + +anyways: your c knowledge will improve :) (if you don't give +up too soon :)) an advice : be sure you understand pointers +very well ! it's one of the more important things in c and also +THE trickiest thing :) many bugs result from having NULL pointers +or from not calling free when using malloc etc ... + + +> +> not really been able to work much at all outside the +> very initial website frontpage due to finals at +> school. I've got a little (Very little) experience in +> C++, but let me tell you what I would like to see.. +> could someone do some sort of heavy commenting on the +> code? Or at least do a cflow with a quick +> description? I understand C a bit, but I need to see +> some type of roadmap, and "read the archives" is a bit +> too vague.. I know it seems like a lot, but if I'm +> ever going to help on the coding end (or if any one +> else is, for that matter) we kinda need to know what's +> going on.. + +you are right ! Dillo is a BIG program and you need to see +some kind of flow in the source. i don't know a lot about +the internals of Dillo yet too :(. i was thinking about +making some kind of overview that lists every module and +every function together with what it is supposed to do/does) +this way we can also try to avoid reimplementing thins like +lists etc ... and: if you find a bug in a function, you can easily +lookup which functions performs a similar task to see if the +bug is there too ... + +one of the better ways to learn something about the code is +reading doc/bytesink.txt or something like that. it explains +what a bytesink is and how it is used in gzilla/Dillo. it also +explains what happens when between the time you enter an url +and when dillo displays your html page. +i think we need more docs like this (btw: this doc needs +updating when the name change is done) + +another way to find out something is by stepping through it with +a debugger (for example ddd, a nice frontend for gdb) + + + +> --- nightstalker wrote: +> > > I really don't like this format: +> > > +> > > > if( blah == blahblah ) +> > > > { +> > > > hello(); +> > > > } +> + +btw: i didn't write this :)) it was a reply to a message i sent where +i said the opposite :) + +> +> I like this. One statement per line. The ultimate +> reason I like this format is because the {'s are +> matched. I know a lot of editors will source +> highlight around the mismatched braces/parens, but +> this makes the code readable without using those +> editors. Just MHO. I mean, we can use indent *.[ch] +> if we really wanna set it up our own ways :) +> + +i like this form better too :) the number of lines of the code +go up, but i think this is more readable than the other form. +btw: this way of indenting is called BSD-style indenting i +believe. + + +> +> > > > if( blah == blahblah ) { +> > > > hello(); +> > > > } +> +> I don't. First off, it's bad form :) It's a single +> line of code following a test. That means you don't +> need the braces. But that's just my compsci +> instructor speaking through me. The bad part about +> this code is that the braces aren't matched up. Throw +> another function around that , and it gets really hard +> to read. Ex: +> + +i always use braces, even for one line of code .. i'll try to explain +why ... +when you want to add something, sometimes a guy will not pay +attention and just add it :) then you get something like : (using +my preferred indenting :) + +if( blah == blahblah ) +hello(); +hello2(); + +i also do it because it just looks better in my opinion :) + + +> +> void somefunc(int count, float& average) +> { +> if (count <= 200) { +> printf("Count is less than or equal to 200"); +> average+=count; +> } +> return; +> } +> +> My problem with this is on a glance over, it doesn't +> look like the decision was exited correctly. Or it +> could appear unclear that the average+= line is part +> of the true case. Or a variety of other things. The +> purpose (as this beginner) sees to indenting is to +> make the code readable. Lining up the braces and +> parens help to isolate blocks on quick run-throughs. +> I already have a ton of work to do once I get free of +> school this semester to learn the ins and outs of +> Dillo. +> + +code like that is the reason why we want to re-indent :) + + +> +> Also.. one other odd thing.. Dillo does not like +> glibc2.1 systems. I recall there being some sorta +> manual fix for gzilla, and I know it'd work on my +> system.. but I can't recall WHAT that fix was. It +> involved (If I recall correctly) something with the +> LDL. Anyone manage to save that? +> + +i don't know about this one ...something i wanted to add : +i tried out the new tarball today (dillo-0.0.1) and it +compiled fine again on my system (with the 0.0.0 i had to +type make inside the src/ dir .. make would fail in the +dillo-0.0.0 dir (due to a configure it did). i'm happy this is +fixed :) + + +> +> Jarrod +> + + + +Re: [Dillo-dev]Re: reindenting + +From: Jarrod Henry - 1999-12-11 17:03 + +Granted, I am VERY new to C. In fact I doubt I could +understand coding at all on this project, I'm just +trying to help in whatever meager ways I can. I've +not really been able to work much at all outside the +very initial website frontpage due to finals at +school. I've got a little (Very little) experience in +C++, but let me tell you what I would like to see.. +could someone do some sort of heavy commenting on the +code? Or at least do a cflow with a quick +description? I understand C a bit, but I need to see +some type of roadmap, and "read the archives" is a bit +too vague.. I know it seems like a lot, but if I'm +ever going to help on the coding end (or if any one +else is, for that matter) we kinda need to know what's +going on.. + + +Now.. + +--- nightstalker wrote: +> > I really don't like this format: +> > +> > > if( blah == blahblah ) +> > > { +> > > hello(); +> > > } + +I like this. One statement per line. The ultimate +reason I like this format is because the {'s are +matched. I know a lot of editors will source +highlight around the mismatched braces/parens, but +this makes the code readable without using those +editors. Just MHO. I mean, we can use indent *.[ch] +if we really wanna set it up our own ways :) + +> > > if( blah == blahblah ) { +> > > hello(); +> > > } + +I don't. First off, it's bad form :) It's a single +line of code following a test. That means you don't +need the braces. But that's just my compsci +instructor speaking through me. The bad part about +this code is that the braces aren't matched up. Throw +another function around that , and it gets really hard +to read. Ex: + +void somefunc(int count, float& average) +{ +if (count <= 200) { +printf("Count is less than or equal to 200"); +average+=count; +} +return; +} + +My problem with this is on a glance over, it doesn't +look like the decision was exited correctly. Or it +could appear unclear that the average+= line is part +of the true case. Or a variety of other things. The +purpose (as this beginner) sees to indenting is to +make the code readable. Lining up the braces and +parens help to isolate blocks on quick run-throughs. +I already have a ton of work to do once I get free of +school this semester to learn the ins and outs of +Dillo. + +Also.. one other odd thing.. Dillo does not like +glibc2.1 systems. I recall there being some sorta +manual fix for gzilla, and I know it'd work on my +system.. but I can't recall WHAT that fix was. It +involved (If I recall correctly) something with the +LDL. Anyone manage to save that? + +Jarrod + +__________________________________________________ +Do You Yahoo!? +Thousands of Stores. Millions of Products. All in one place. +Yahoo! Shopping: http://shopping.yahoo.com + + + +Re: [Dillo-dev]Re: reindenting + +From: nightstalker - 1999-12-11 16:45 + +Jorge Arellano Cid wrote: + +> Hello, +> +> I really don't like this format: +> +> > if( blah == blahblah ) +> > { +> > hello(); +> > } +> +> I prefer this method: +> +> > if( blah == blahblah ) { +> > hello(); +> > } +> +> That's my argument. +> -James McCollough +> +> Me too! +> -Jorge Arellano Cid +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO :) + +sammy. + +ps: i'll learn to live with it :) + + + +Re: [Dillo-dev]I am in doubt what to do! + +From: Jorge Arellano Cid - 1999-12-11 11:41 + +Luca, + +Good to see you posting here! +(I was very worried about the list failing to reach it's +susbscribers) + + +> Hello World, +> +> I have to patch gtkgzwview.c but I don't know what to do. +> +> I thought, from gtk_gzw_view_new to: +> 1. a_gtk_Dw_view_new +> 2. a_Dw_gtk_view_new +> 3. a_Dw_view_new +> +> Which do you want? + +Number 2. + +Why? +Cause as a wrote before, when asked the same, (I don't remember +where; blesses to the list), I see Dillo Widget as a whole +module. So, from #2 it would be clear that the module is Dillo +Widget, that the functionality is view_new and that it's gtk +based. Finally I should name the source 'dillogtkview.c' later... + + + +Jorge.- + + +Pd: Haven't seen your vote on braces placement yet! + + + +[Dillo-dev]I am in doubt what to do! + +From: Rota Luca - 1999-12-11 10:44 + +Hello World, + +I have to patch gtkgzwview.c but I don't know what to do. + +I thought, from gtk_gzw_view_new to: +1. a_gtk_Dw_view_new +2. a_Dw_gtk_view_new +3. a_Dw_view_new + +Which do you want? + +Ciao, +Luca + + + +Re: [Dillo-dev]Re: reindenting + +From: Jorge Arellano Cid - 1999-12-10 10:37 + +Hello, + +I really don't like this format: + +> if( blah == blahblah ) +> { +> hello(); +> } + +I prefer this method: + +> if( blah == blahblah ) { +> hello(); +> } + +to quote from the CodingStyle document in the linux kernel +documentation: + +Chapter 2: Placing Braces + +The other issue that always comes up in C styling is the placement of +braces. Unlike the indent size, there are few technical reasons to +choose one placement strategy over the other, but the preferred way, as +shown to us by the prophets Kernighan and Ritchie, is to put the opening +brace last on the line, and put the closing brace first, thusly: + +if (x is true) { +we do y +} + +However, there is one special case, namely functions: they have the +opening brace at the beginning of the next line, thus: + +int function(int x) +{ +body of function +} + +Heretic people all over the world have claimed that this inconsistency +is ... well ... inconsistent, but all right-thinking people know that +(a) K&R are _right_ and (b) K&R are right. Besides, functions are +special anyway (you can't nest them in C). + +Note that the closing brace is empty on a line of its own, _except_ in +the cases where it is followed by a continuation of the same statement, +ie a "while" in a do-statement or an "else" in an if-statement, like +this: + +do { +body of do-loop +} while (condition); + +and + +if (x == y) { +.. +} else if (x > y) { +... +} else { +.... +} + +Rationale: K&R. + +Also, note that this brace-placement also minimizes the number of empty +(or almost empty) lines, without any loss of readability. Thus, as the +supply of new-lines on your screen is not a renewable resource (think +25-line terminal screens here), you have more empty lines to put +comments on. + +(end quote) + +That's my argument. +-James McCollough + +Me too! +-Jorge Arellano Cid + + + +[Dillo-dev]CVS information + +From: - 1999-12-10 02:18 + +Here's a brief explanation of CVS, as well as links to additional +information. + +CVS is a beautiful thing. It allows a set of developers to work on a +single set of sources, and allows users to get daily updates to the +source. Generally you have anonymous read access set up, so anyone can +get the sources, and you also have write access for a select few who +can make changes. + +quoted from the cvs man page: + +CVS is a version control system, which allows you to keep +old versions of files (usually source code), keep a log of +who, when, and why changes occurred, etc., like RCS or +SCCS. Unlike the simpler systems, CVS does not just oper- +ate on one file at a time or one directory at a time, but +operates on hierarchical collections of directories con- +sisting of version controlled files. CVS helps to manage +releases and to control the concurrent editing of source +files among multiple authors. CVS allows triggers to +enable/log/control various operations and works well over +a wide area network. + +cvs keeps a single copy of the master sources. This copy +is called the source ``repository''; it contains all the +information to permit extracting previous software +releases at any time based on either a symbolic revision +tag, or a date in the past. + +links: + +the homepage of cyclic software, makers of CVS: +http://www.cyclic.com + +a page with links to documentation and other tools: +http://www.loria.fr/~molli/cvs-index.html + + + +[Dillo-dev]Reindenting + +From: Jorge Arellano Cid - 1999-12-10 02:13 + +Hi! + + +I don't know why, but my former message got to the list +incomplete... + +I'm polling you on the '{', '}' placement as ilustrated in the +former msg. +Everyone in the name change has a vote! + +Vote here, to the list. + + +Jorge.- + + +Pd: I don't know if you're receiving this messages, so please +acknowledge it to my by email. Subject: dillo-dev OK + + + +[Dillo-dev]Re: reindenting + +From: Jorge Arellano Cid - 1999-12-10 02:01 + +On Thu, 9 Dec 1999, nightstalker wrote: + +> What's the way you are going to use for the re-indenting ? (i know it's +> a topic of it's own but .. :) +> +> i prefer : +> +> if( blah == blahblah ) +> { +> hello(); +> } +> +> i hate: +> +> if( blah == blahblah ) { +> hello(); +> } +> +> :)) +> +> if you decide to re-indent the source like the second style, i'll live +> with it :) i was just a bit curious :)) +> +> +> +> + + + +[Dillo-dev]Halfway advanced tarball + +From: Jorge Arellano Cid - 1999-12-09 23:29 + +Hello! + +I'm just uploading the "new" tarball to the website. It has +every single patch I received integrated & tested; chances are +you'll like it very much. + +The effort is not completed though... + +With this second half of the naming process, let's start it +over again, i.e. unpack the new tarball, ./configure; make, +create the obj/ dir, copy the objects there, strip them and start +the patching process. + +Please do it by module, don't concatenate patches. +And if your patch needs to modify one of the sources within +the src/ subdirectories (IO, MIME, URL or Cache), attach the +patches for those as normal patch files, one patch, one source. +Just issue a normal 'diff -bu' on them. + + +Enjoy! +Jorge.- + + +Pd: +http://academico.inf.utfsm.cl:81/~jcid/Dillo/dillo-0.0.1.tar.gz + + + +[Dillo-dev]Patching news + +From: Jorge Arellano Cid - 1999-12-09 19:23 + +Hi, + +For those of you that're still praying, relax, I succeeded +with every single patch (thanks above). + +Now I'm cleanning my source tree and when finished, I'll put +it at the website so we can continue working from it. That'll be +very soon (give me 4 hours). I'll announce it here, OK? + + +Jorge.- + + + +[Dillo-dev]Patching hell! + +From: Jorge Arellano Cid - 1999-12-09 12:11 + +Hello everyone! + +Currently I have a patching hell here!!! + +...but Don't worry, I can handle that; the fact that matters +is that I *do* dislike it very much. + +Please: stop sending me patches for now. I'll try to integrate +the ones I have now (Sammy's & James') and will put out an +intermediate level source tarball to continue from. + +Please don't send me a huge integrated radioactive patch :-) +That's really hard to manage. Send me "per module" patches. + +I'm currently struggling a 55 Kb. patch.... + + +Well, I feel the need to thank everyone collaborating with +this effort, cause I've been there and I know how hard it is, and +what a tough work it requires. + +I've had the pleasure of a short debugging session with the +halfway-completed-tarball and it really pays off. You'll +experience that soon, when I slay the big dragon in! + +We're cleanning the house, and it really looks&feels better +although not completed yet; wait until I show you the identated +version after the patching effort succeeds! That will be +Champaigne time!!! + + +Jorge.- + + +Pd: Sammy, I'm putting my best efforts on it. + + + +[Dillo-dev]CVS up + +From: - 1999-12-09 01:52 + +hello, + +A CVS repository for dillo is up, consisting of the dillo-0.0.0 +release. to have anonymous read access, set your CVSROOT environment +variable to: + +pserver:anonymous@cv...:/cvsroot/dillo + +and do a 'cvs login'. at the password prompt, simply hit enter. + +to checkout, do a 'cvs checkout dillo'. + +to obtain write access, please contact either jorge or me for details. + +-James McCollough + +P.S. if cvs.dillo.so....net doesn't resolve, use +cvs1.so....net:/cvsroot/dillo + + + +[Dillo-dev]name change within subdirectories + +From: Jorge Arellano Cid - 1999-12-09 01:47 + +Hi, + +I've been told that the progress monitor doesn't work with +subdirectories... +But it does! +Just submit the file name, not including the directory and +that'll do it. I've put an example there. + +(if I'm wrong, let me know) +Jorge.- + + + +[Dillo-dev]Patching hint + +From: Jorge Arellano Cid - 1999-12-08 20:53 + +Hi, + +I just managed to integrate gzwimage.c patch (by Luca) in a +secure way. I mean, with identical object files. Here's what I +found: g_print() and g_return_if_fail() integrate a function name +to the object file (as a way of being able to provide that info +at run time), and that's why the object files differ. + +A simple way of avoiding this object file incongruencies, is +to change those functions, commenting them out in the original +file (unpatched), making the object for it (save it stripped to +obj/) and do the naming change process as usual. You'd eventually +end up with identical object files. If that's true, submit the +original patch to me with a note about that. + + +Jorge.- + + + +[Dillo-dev]Naming&coding, hints and News + +From: Jorge Arellano Cid - 1999-12-08 14:56 + +Hello World! + +This is my first message to the list. We have a mailing list!!! +Thanks James, your work has saved me precious time that I put to +the patching effort. + +I'm very happy cause now you'll get more informed about project +activities and related stuff. (I told James to add the "crew" to +the list but, if you're feeling spammed, please let him know and +to remove you (you can do that yourself too)) + + +============ +News & Hints +============ + +------------------------------------------------ + +As the patches began to flow to my email account (keep sending +them to me, not to the list), I noticed that sometimes the patch +fails, even though it was done right, that's why I changed the +diff format to 'unified'. It works better for me. + +Edit your 'mkpatch' script an before the last line you'll find: + +diff -b patch/ ./ > ptch + +change it to: + +diff -bu patch/ ./ > ptch + +that's all (or if you hesitate, download the new version from +the web site). + +That'll make things simpler on the patching side ;) + +------------------------------------------------ + +If you compile and get undefined references to renamed +functions, that's just cause you forgot to erase the stripped +object file. + +------------------------------------------------ + +If you get to the progress-tracker and see the word 'DONE', it +means I already succeeded integrating it to the new tarball. + +------------------------------------------------ + +James as ked me what to do with structs, here's a quote: + +> for structs, does the 'a_' prefix show up at all? + +That's a good idea! + +I haven't included that things (neither the gzilla named +structs and vars), and I think that it was good not doing it. +Why? +Because the current naming process is complex enough to scare +our developers, and that kind of extra work would narrow our +scope of collaborating people working on it. + +But that is to be accomplished on a second stage, and frankly I +haven't thought of the struct-naming based on scope; that's why I +found your idea good. + +Yes, probably that will be the future naming convention for it. +I do like it that way. + +I.E. Exported structs prefixed with 'a_' and internal ones +named freely, but declared static! + +Perfect. +Don't do it now though, let it happen at the second stage. + + +> Would GzillaImgSink struct become ImgSink or a_ImgSink? + +As long as it is exported, and following the former directives, +it would be renamed 'a_ImgSink'. + +But, let's think of another exported struct, that's named +simply 'mystery', then it should become 'a_Imgsink_mystery' just +to show where it came from. Nice!!! + + +------------------------------------------------ + +Please remember that the naming effort is concurrent and very +very fragile. We need to make it exactly as the 'manual' says. As +a matter of fact, I put the manual on a VC an actually use it +when making the changes!!! + +------------------------------------------------ + +Luca: I tried to integrate your gzwimage.c patch, but the +object files differ. I went thorough the patch itself, and found +nothing suspicious :(, I tried from a clean source, but failed +again so, would you mind sending me a new version? (using the new +mkpatch); otherwise it will have to wait every other single patch +to get in :( + +------------------------------------------------ + +thankful +Jorge.- + + + + +Pd: Does anyone know what LOL means? :) + + diff --git a/old/oldmail/200001.txt b/old/oldmail/200001.txt new file mode 100644 index 0000000..5bfcee1 --- /dev/null +++ b/old/oldmail/200001.txt @@ -0,0 +1,313 @@ +[Dillo-dev]News! + +From: Jorge Arellano Cid - 2000-01-13 14:41 + +HI there! + +Time for good news!: + +* Finally, I made the arrangements to keep working full-time on Dillo +project (At least for some months). I think that will significatively help +the whole project, specially at this critical fixing-redesignning stage. + +* Updated the web site + +* Fixed several things inside the code (including severe memory leaks). + + +Currently I'm heavily changing the dicache, imgsink and Image modules +(code, algorithms and ADTs). Please focus on bug fixing, and expect big +changes in the next release! + +I'll try to devote all my time to this task; please excuse me if I +procrastinate other subjects... + + + +Jorge.- + + + +Re: [Dillo-dev]Memory Leak + +From: Jorge Arellano Cid - 2000-01-07 15:09 + +Luca, +(& everyone) + +> Hi, +> +> I'm testing Dillo and I don't like what I see. I've changed malloc in +> g_malloc, free in g_free and realloc in g_realloc in all the source tree. +> I've recompiled my glib with mem_profile enabled, at the end of main() +> I've added g_mem_profile() just before the return. + +Nice! +Did you just run a script to change them? +(please send it to me) + +> +> Test: +> Run Dillo and then press (to close Dillo): +> 143 Kb allocated +> 35 Kb freed +> 108 Kb in use :( +> +> Run Dillo, open http://www.polito.it, open http://www.gzilla.com (here I got +> GLib-WARNING **: freeing previously freed memory :( ), open segfault.org, +> : +> 2.8 Mb allocated +> 1.8 Mb freed +> 1 Mb in use :( +> +> Run Dillo, open http://www.polito.it, open Dillo Home Page, open http://www.gzilla.com, +> (this time I have't got the GLib warning): +> 1.9 Mb +> 1 Mb +> 0.9 Mb in use +> +> Maybe we'd solve this bug to stabilize Dillo, too. + +Of course. + +Some time ago, Daniel (Roberts) posted a very similar report to gzilla +mailing list (he worked with 'leaky' or similar), the fact that matters is +that Dillo doesn't deallocate the memory it uses before exiting; it leaves +all the cleanning work to the OS. +Specially significative is the DIC (decompressed image cache), wich I'm +extensively working now; It allocates memory for every single image Dillo +loads (uncompressed allocation). +There're also other resources (I remember five lists of allocated stuff) +that don't get deallocated when finishing... + +I think it would be very interesting to write the deallocating functions +(as a_Dicache_free_all for instance), call them before exiting and +make a review of what happens then. + +Personally, I've worked enough those modules, up to be deeply convinced, +that such a test is required. I can even try to write some of those +deallocating functions quickly. + +Actually, I've worked the code a lot, and would like to standarize it to +g_malloc and friends (as you did), integrate your latest patch, write +the deallocating functions, and make a new release to work with. + + +Jorge.- + + + +[Dillo-dev]Memory Leak + +From: Luca Rota - 2000-01-06 15:35 + +Hi, + +I'm testing Dillo and I don't like what I see. I've changed malloc in +g_malloc, free in g_free and realloc in g_realloc in all the source tree. +I've recompiled my glib with mem_profile enabled, at the end of main() +I've added g_mem_profile() just before the return. + +Test: +Run Dillo and then press (to close Dillo): +143 Kb allocated +35 Kb freed +108 Kb in use :( + +Run Dillo, open http://www.polito.it, open http://www.gzilla.com (here I got +GLib-WARNING **: freeing previously freed memory :( ), open segfault.org, +: +2.8 Mb allocated +1.8 Mb freed +1 Mb in use :( + +Run Dillo, open http://www.polito.it, open Dillo Home Page, open http://www.gzilla.com, + (this time I have't got the GLib warning): +1.9 Mb +1 Mb +0.9 Mb in use + +Maybe we'd solve this bug to stabilize Dillo, too. + +Ciao, +Luca + + + +Re: [Dillo-dev]New release + +From: Jorge Arellano Cid - 2000-01-05 23:45 + +Sammy, + + +> What is the library for the png routines ? i get undefined references +> from png.c :) + +Sorry, it seems I'll have to include a check within the +autoconf stuff... + + +The PNG support requires libpng-1.0.5 or better +(available at http://www.cdrom.com/pub/png/) + +... it also requires zlib-1.1.3 or better +(available http://www.cdrom.com/pub/infozip/zlib/) + +but if you're running Redhat, you'd better grab the rpms. + + +Jorge.- + + + +Re: [Dillo-dev]New release + +From: - 2000-01-05 23:21 + +its libpng, and it can be downloaded from ftp.cdrom.com or +metalab.unc.edu, or just about any big ftp site. I also had to add -lz +to the makefile to link with zlib (That's probably your problem). + +-James McCollough + + + +Re: [Dillo-dev]New release + +From: nightstalker - 2000-01-05 22:05 + +What is the library for the png routines ? i get undefined references +from png.c :) + +sammy + + + +[Dillo-dev]New release + +From: Jorge Arellano Cid - 2000-01-05 01:02 + +Hi! + + +Finally dillo-0.0.4 is finished, and ready for download. It +includes several changes, bug fixes and improvements; some things +didn't make it into the tarball due to stability concerns, but I +hope to polish them enough to add them in the next release. +Anyway you'll find plenty of changes in the Changelog. + +I hope you enjoy this release. + +Caveat: The background color support is not yet completed and +if you happen to browse a page with BLACK background, you'll not +see the text! -- Luca is currently working on this. + + +Jorge.- + + +Pd: James, tomorrow I'll send you a detailed answer in regard to +the progress bar code; I liked it very much and I think we're a +few touches away from a first class meter! + + + +Re: [Dillo-dev]What's about i18n (internationalization)? + +From: Jorge Arellano Cid - 2000-01-04 14:00 + +Luca, +(and everyone!) + +> Hi, +> in this days I've tried to add i18n to Dillo. I'm using gettext package. +> I've added the po/ and intl/ into source tree, modified the configure.in and +> added the necessary code to dillo.c and menu.c thus I've tried to translate +> some menu items in Italian (it works !). +> +> So my question is: Are we interested in i18n? + +Of course it's a desirable feature, but I'd rather prefer we +focus on bug fixing now; I've been deeply digging the sources +these days and I'm somewhat scared on what I've found. + +Please don't get me wrong, I do like those new features, what +I'm trying to do is to finish the stabilization process, and end +up with a rock-solid browser that's easy to understand and to +extend. BTW: when adding the PNG decoding routines, Geoff used a +very similar aproach to what he saw with GIF and JPG. But the +underlying mechanism was broken, so he was not able to know in +advance that it wasn't his code's fault when some images were not +rendering... I've experienced that several times before, and it's +incredibly discouraging to start trying to find were the bug is +(or whether your fault or not), in a very big code base that you +don't know, that's undocumented and sometimes misleadingly +commented... + +I don't want our developers to experience that painful coding +facts, and that's why I prefer to stabilize, clean and fix what +we have now, and after that, to focus on what we'd like to add or +improve. As a matter of fact, I've found several more bugs while +working the code and I'll introduce them into the bug track ASAP. + +Please don't be deceived by a pretty face, Dillo _IS_ very +BUGGED now, we haven't reached the safe extensibilty milestone +yet. You have been warned... + + +------ + +Luca: +In regard to 'text', 'link', 'vlink' and 'alink', they are +highly required now (cause bgcolor will be included in the next +release). Please make a feature-fault entry at the bug-track and +keep up the good job! + + +sincerely +Jorge.- + + +Pd: I'll try to release dillo-0.0.4 today. + + + +[Dillo-dev]What's about i18n (internationalization)? + +From: Luca Rota - 2000-01-03 14:50 + +Hi, +in this days I've tried to add i18n to Dillo. I'm using gettext package. +I've added the po/ and intl/ into source tree, modified the configure.in and +added the necessary code to dillo.c and menu.c thus I've tried to translate +some menu items in Italian (it works !). + +So my question is: Are we interested in i18n? + +Ciao, +Luca + + + +[Dillo-dev]Site is UP!!! + +From: Jorge Arellano Cid - 2000-01-02 00:59 + +Hi everyone! +2000 year greetings to you! + +Quick Good News: + +- Our site is working again!!! +(Go & check it please :) + +- Internet is working OK (No big Y2K problems here) + +- dillo-0.0.4 will be great! + + + +Jorge.- + + diff --git a/old/oldmail/200002.txt b/old/oldmail/200002.txt new file mode 100644 index 0000000..20eee44 --- /dev/null +++ b/old/oldmail/200002.txt @@ -0,0 +1,295 @@ +Re: [Dillo-dev]New release & documentation + +From: nightstalker - 2000-02-09 23:53 + +jcid@ma... wrote: + +> Sammy, +> +> Glad to see you again! +> + +Glad to be back too :) (although work is keeping me busy) + +> +> > can anyone from the mailing list give me the url to the webpage? +> +> Yes! :) +> +> > i reinstalled my system but i forgot to copy my netscape +> > bookmarks :) +> +> Deja vu (Did I spelled it right?) +> +> Ok Sammy, we're at: +> +> http://academico.inf.utfsm.cl:81/~jcid/Dillo/project.html +> +> and you'd surely want to download: +> +> http://academico.inf.utfsm.cl:81/~jcid/Dillo/dillo-0.0.5.tar.gz +> +> enjoy! +> +> Jorge.- +> +> Pd: Feedback welcome +> + +it compiled like a breeze over here (running slackware 7 with newest +version of glib & +gtk ) +ran very well too .. allthough a bug that i fixed back when dillo was +gzilla is back :) +(as your first action : select bookmarks -> add bookmark ... +'segmentation fault' ) +i'll see if i can fix it again (it shouldn't be so hard) + +i still notice that sometimes dillo starts taking a lot of cpu power (it +doesn't appear to be +doing anything though). I've noticed this with other versions of dillo +too. + +congratulations on fixing the image code .. i could now surf to +http://www.tuxedo.org/~esr/ and +see all jpgs and png's :) + + + +Re: [Dillo-dev]New release & documentation + +From: - 2000-02-08 14:47 + +Sammy, + +Glad to see you again! + +> can anyone from the mailing list give me the url to the webpage? + +Yes! :) + +> i reinstalled my system but i forgot to copy my netscape +> bookmarks :) + +Deja vu (Did I spelled it right?) + +Ok Sammy, we're at: + +http://academico.inf.utfsm.cl:81/~jcid/Dillo/project.html + +and you'd surely want to download: + +http://academico.inf.utfsm.cl:81/~jcid/Dillo/dillo-0.0.5.tar.gz + +enjoy! + + +Jorge.- + + +Pd: Feedback welcome + + + +Re: [Dillo-dev]New release & documentation + +From: nightstalker - 2000-02-06 15:56 + +hi, + +can anyone from the mailing list give me the url to the webpage ? +i reinstalled my system but i forgot to copy my netscape +bookmarks :) + +sammy + + + +[Dillo-dev]New release & documentation + +From: Jorge Arellano Cid - 2000-02-04 02:59 + +Hi! + +Fresh news for you: + ++ Just released dillo-0.0.5.tar.gz (DL. from website) ++ There're several improvements (read the Changelog) ++ Made minor updates to the web site ++ Wrote some documentation (attached with this mail) + + +Well, before you download the source, let me tell you that +this release features a couple of progress bars, but *don't +expect them to work*, that will be fixed later. The problem is +that they were developed while I was changing the image fetching +routines... When I finish that, they'll get right. + +The second thing you should be aware of, is that although +rendering is significatively improved, stability is very fragile. +No, that's not due to rendering, but to socket abort handling. As +a matter of fact, Dillo-0.0.5 is very stable on local networks. + +Needless to say, I'll focus on finishing the image fetching +stuff, write some more docs, and then get to the sockets part. + +Finally, here I quote the notes I took while reviewing Dillo +widget code, they are to be completed, corrected and improved. +They were useful for me, so let's share them! + + +Sicerely +Jorge.- + + +>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> + +------------ +DILLO WIDGET +------------ + +------ +Resize +------ + +Widget resizing and repainting can be initiated by +Dw_gtk_view_request_resize and Dw_gtk_view_request_paint +functions. The resizing process is carried by an idle function +(Dw_gtk_view_idle_func) that's launched upon request. + +Using an idle function to do it ensures good performance, +as long as the resizing stuff gets done when the browser is not +doing anything else. + +To start the resizing, a_Dw_request_parent_resize must be +called, but beware, this routine is not a straightforward +invocation of the widget method. Rather, it uses a resize flag +mechanism; if the widget's resize flag was already set, nothing +happens but, if not, the flag is set and the request_resize +method on the widget parent is called. +The actual resize is done later, by an idle function that +discriminates upon those flags. +The resize flag is cleared later by a_Dw_size_nego_y. + +The horizontal and vertical size methods are a_Dw_size_nego_x +and a_Dw_size_nego_y. They call the appropriate widget-class +method. For instance: if you call a_Dw_size_nego_x(wdg) and wdg +is of type DwPage, then Dw_page_size_nego_x will be called. + +a_Dw_size_nego_x is called with the widget and requested width +as parameters. a_Dw_size_nego_y is called with the widget and, +width & height inside an allocation structure (that's why +size_nego_x method isn't implemented sometimes). Anyway, the size +negotiation sequence calls a_Dw_size_nego_x first, and after that +it calls a_Dw_size_nego_y. If size_nego_x is NULL, there's no +problem, but size_nego_y must be defined. + + +Some vars: + +y_ascent = image height +y_descent = 0 (for images) +x_size = gdk_string_width(gdkfont, text) | widget width + + +------- +Repaint +------- + +Dw_gtk_view_request_paint gets called whenever a child widget +needs a repaint (generally issued as the request_paint method of +the container class). The repaint rectangle is added to the +request repaint region, and an idle process is started to repaint +it if necessary (Dw_gtk_view_idle_func). + +The interesting fact is that Dw_gtk_view_idle_func performs +both, resizing and repainting. + + +------------------ +Rewrap (new stuff) +------------------ + +The rewrap stuff is not completely designed yet. What I +implemented is a workaround that's somewhere between a hack and a +clean patch; Yes, it's a tradeoff that lets the browser handle +image resizes, and is tuned enough to be very fast. + +The rewrap function is set in Dw_page_request_resize as an +idle function; that way, a single rewrap is done, instead of one +per image resize. Even more, if the image is cached, there's no +rewrap call cause the image size is already known. + +How is it done? +a_Dw_image_size function requests a parent resize. When the +resize-request reaches the top class, resize methods are called; +that way, Dw_page_request_resize is run (at its turn). Inside +Dw_page_request_resize, the page's rewrap-request-flag is set and +an idle rewrap is launched. + + +----------- O ----------- + + + +Re: [Dillo-dev]Progress + +From: Luca Rota - 2000-02-01 21:20 + +On Mon, 31 Jan 2000, Jorge Arellano Cid wrote: + +> Hi! +> Is there anybody out there? :-) + +I'm always here. :) + +> Tomorrow will be testing time, and you can expect a new release +> soon (maybe three or four days, gimme' some feedback). + +I'll wait ;) + +Ciao, +Luca + + + +[Dillo-dev]Progress + +From: Jorge Arellano Cid - 2000-02-01 01:37 + +Hi! +Is there anybody out there? :-) + + +Well, finally the image rendering bug is fixed; that made a big +change in Dillo (and a lot of work and changes in the inside). +Tomorrow will be testing time, and you can expect a new release +soon (maybe three or four days, gimme' some feedback). + + +Current changelog looks like this: + +- * Added progress bars (to be improved) +Patch: James McCollough, Jorge Arellano Cid +- * Rearranged, changed and commented the decompressed image cache code +* Fixed autoconf stuff to include zlib +* Added memory deallocating functions to cache, dicache, socket, http & dns +* Fixed memory leaks in jpeg.c, png.c and gif.c +* Made several changes in dw_page.c +* Made several "standarizing" changes all over the code. +* Introduced ist.hsource +* Fixed image rendering (Fixed algorithms and data structures) +Patches: Jorge Arellano Cid +- * Added support for extand inkcolors inside tags +* Standarized all memory management to glib functions +* Fixed the plugin API to work again (forked) +* Removed a warning (remove not implemented for Dw_view and Dw_scroller) +* Solved the page-without-title bug in bookmarks. +Patches: Luca Rota + + + +Best regards +Jorge.- + + diff --git a/old/oldmail/200003.txt b/old/oldmail/200003.txt new file mode 100644 index 0000000..57b7fbf --- /dev/null +++ b/old/oldmail/200003.txt @@ -0,0 +1,200 @@ +[Dillo-dev]Developer release + +From: Jorge Arellano Cid - 2000-03-30 22:50 + +Hi everyone! + +Today dillo-0.1.0.tar.gz is ready for download. It will be our +first public developer release! + +When James finish setting it to on the sourceforge ftp server, +I'll add a download link to the home page, announce it to the gtk +devel mailing list, and it will be public! + +Comments are welcomed. + + +Jorge.- + + +Pd: Haven't got any feedback on the former release yet :-| + + + +[Dillo-dev]Activity + +From: Jorge Arellano Cid - 2000-03-15 16:16 + +Hi, + +Has anyone downloaded dillo-0.0.6? +(Haven't received a single comment yet...) + +Jorge.- + + + +[Dillo-dev]New release + +From: Jorge Arellano Cid - 2000-03-09 17:58 + +Hi! + +Finally, dillo-0.0.6.tar.gz is out! +Several bug fixes, feature additions and docs had been added. +Please check it carefully and send me comments about the documentation. + +Beware: +- The Image progress bar is not working properly, it needs further +work. +- Sometimes the IP transfer blocks the browser. I'm working on that... +- Sometimes images are rendered as a white rectangle. Any clues? + + +Finally, Luca added preferences that are to be set using a +readable config file. I included a sample one within the tarball +(dillorc). Copy it to your .dillo/ directory and adjust to your taste! + +Ah, I also updated the web site. Check it out! + + +Jorge.- + + + +[Dillo-dev]Lots of news! + +From: Jorge Arellano Cid - 2000-03-03 19:03 + +Hi guys! + +Although mailing list activity had been dead, my email box has +showed some traffic. A lot of things are happening now, and I wish +to share the with all of you. + +dillo-0.0.6 is almost ready for release (less than a week more) and +I want dillo-0.0.7 to be our first developer's release; Let's work +toward that goal! + +I've been working ironing some bugs (check the bug track) and writing +DOCUMENTATION!!! All that stuff will be inside the next tarball in the +doc/ dir. Please check it carefully and send me some feedback about it. +What did you like? What you want extended? --things like that. +If you feel confident enough to send me your extensions, please do so. + +The other part (the one that has taken most of my time) is the table and +frames extensions to dillo parser. There were several alternatives, among +them I found: + +1.- gtk-xmhtml +2.- xml (Entity engine) +3.- xhtml +4.- gtkhtml +5.- mMosaic source code + +The main point was to find a HTML-rendering library or some code +that can be adapted to dillo. + +Briefly: + +1.- Is deprecated. (Dead, as Miguel de Icaza told me) + +2.- This is very interesting and consists on writing a new HTML parser +but having all the rendering done by the Entity engine. Entity is a new +project by Ian Main (he also worked in gzilla a long time ago). Entity is +an XML parsing engine, written in C that can be used to develop apps. +specified as XML with functionality implemented in another language. +(Interesting, but I need more time to evaluate it. --Spent three and a +half hours on IRC with Ian talking about it...) +If you want to investigate, go to: +http://entity.evilplan.org + +3.- XHTML is a family of current and future document types and modules +that reproduce, subset and extend HTML 4. XHTML family doc. types are XML +based, and ultimately are designed to work in conjunction with XML-based +user agents. +What does it means? That if we implement an XHTML parser, we should +be able to handle that, some more and, with some little magic, HTML 4.0 + +4.- gtkhtml is the html library that will superseed gtk-xmhtml in the +gnome project. I tryed to try it :) as Miguel suggested, but id depended +on several other gnome-libs (gnome-xml, glibwww, gnome-print, gtkhtml...) +I gave up. It was impressively big, and the meaning of having a light +weight browser is absolutely lost. + +5.- mMosaic claims to support TABLES and one level of frames. Maybe +we can look there. (Zero research :( ) + +Well, it seems we'll continue extending dillo widget to support tables +and frames until we found a better way to do the job. + +Opinions&suggestions are welcome. + + +------ + +Sammy, + +I included all your patches in dillo-0.0.6 + +> it compiled like a breeze over here (running slackware 7 with newest +> version of glib & gtk) + +Good! (I plan to install Slk 7 soon) + +> i still notice that sometimes dillo starts taking a lot of cpu power +> (it doesn't appear to be doing anything though). I've noticed this with +> other versions of dillo too. + +This worries me from time to time. I've never been able to reproduce +the bug, and the only thing I can think of, is a surviving thread (maybe +the scheduling one) from a KILL signal. Pleas check it. +'ps aux | grep dillo' +When you first run dillo, there should be one process. After the first +DNS query, there should be 2. And from then and on, those two threads +remain but when resolving a query, one more thread per query is +temporarily added. + +> congratulations on fixing the image code .. i could now surf to +> http://www.tuxedo.org/~esr/ and +> see all jpgs and png's :) + +Thanks a lot. + +Finally: Are you working on the reload button? + +------ + +James: + +I've been working the progress bars code. Finally moved them to the +upper part and at least the text one is working reasonably well. I have +to put further work with the image one though. +I hope to improve those a bit before releasin dillo-0.0.6. + +Ah, I need my sourceforge account to have admin permissions! +Currently it recognizes me as a user (No uploads, FTP, HTML site...) + +If you're stuck with bug #5, you'll find some good info in the docs I +wrote (wait next release or send me an email request) + + +----- + +Luca, + +I hope to have answered some of your questions with the first part +of this book :) + +> What's about gtk-app-devel-list@re... (gtk mailing list) and the +> so....net' news? + +The suggestions you gave to my gtk-oriented-announce-place request, seem +OK to me. Lets keep it that way, unless a better one pops-up. + + + +Sincerely +Jorge.- + + diff --git a/old/oldmail/200004.txt b/old/oldmail/200004.txt new file mode 100644 index 0000000..ba80bfb --- /dev/null +++ b/old/oldmail/200004.txt @@ -0,0 +1,906 @@ +Re: [Dillo-dev]Sourceforge + +From: Jorge Arellano Cid - 2000-04-24 19:15 + +Hello World! + + +First, I'd really appreciate feedback on my ematic.com email address, +but I still don't know if it is world reachable. +(If you can't deliver there, use jcid@ma... instead). + + +On Sun, 23 Apr 2000 bigdaddy@ll... wrote: + +> I noticed that dillo is only using about 30% of all the sourceforge +> resources that it could. + +Excellent, if you feel like updating it... + +> I.E. - The there is no webpage at http://dillo.so....net + +I wish it to be a mirror rather than a URL redirection. +I'll keep the bug track engine and the primary site in the new server +(dillo.inf.utfsm.cl) and use sourceforge to handle heavy network traffic +(downloads and home page). + +> The ftp on sourceforge is very outdated. + +Update it, no problem (please delete the old tarball) + +> The CVS hasn't been updated in a while + +Not first priority. If updated, it would work as a checkout only. + + +> I think it might be a good idea to update the sourceforge stuff. It might +> help to bring more developers into the project. + +Thanks, please contact James and ask him the SW permissions to do that. +It would be nice to announce the project in sourceforge news too... +Please remember that this is a DEVELOPER's release. Not for USERS. + +> Switching over to sourceforge's bugtracking might not be a bad idea, but +> since we already have an engine for that (though last time I checked it +> wasn't working) it is not a high priority. + +The bug-track is healthy and working, check it at: + +http://dillo.inf.utfsm.cl/ + +(it is was designed for this project, so we'll keep it) + + + +Jorge.- + + + +[Dillo-dev]Sourceforge + +From: - 2000-04-24 01:45 + +I noticed that dillo is only using about 30% of all the sourceforge +resources that it could. +I.E. - The there is no webpage at http://dillo.so....net +The ftp on sourceforge is very outdated. +The CVS hasn't been updated in a while +So on, and so forth. +I think it might be a good idea to update the sourceforge stuff. It might +help to bring more developers into the project. +At a minimum- make a re-direct on the dillo.so....net page to the +real homepage, and update the ftp tarball. +Switching over to sourceforge's bugtracking might not be a bad idea, but +since we already have an engine for that (though last time I checked it +wasn't working) it is not a high priority. + +Does anybody else have any thoughts? + +-Mark + +"You can't get a blue screen on a black and white monitor." + + + +Re: [Dillo-dev]ematic.com + +From: - 2000-04-22 21:28 + +If this gets to you, then no ;-) + +-Mark + +"You can't get a blue screen on a black and white monitor." + +On Fri, 21 Apr 2000, Jorge Arellano Cid wrote: + +> +> Hi, +> +> Has anyone experienced trouble sending mail to jcid@em...? +> +> +> Jorge.- +> +> +> +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev +> + + + +[Dillo-dev]ematic.com + +From: Jorge Arellano Cid - 2000-04-21 18:19 + +Hi, + +Has anyone experienced trouble sending mail to jcid@em...? + + +Jorge.- + + + +[Dillo-dev]New server + +From: Jorge Arellano Cid - 2000-04-20 14:25 + +Hi! + + +Just finished moving the web site! + +Take a look at: http://dillo.inf.utfsm.cl/ + + +Jorge.- + + + +[Dillo-dev]Progress + +From: Jorge Arellano Cid - 2000-04-20 01:44 + +Hello crew! + +The new server is almost set; just need to recompile the CGIs +and it will be ready! + +The cache rewrite is in progress, I just finished writing a +whole new IO engine; the cache will be based on it, and the rest +of Dillo will use the cache API. + +Please remember that after that's done, and the CPU hogging +problem is fixed, we'll make a freshmeat announce! + + +Regards +Jorge.- + + + +[Dillo-dev]Current tarball + +From: Jorge Arellano Cid - 2000-04-13 03:30 + +Hi! + + +You can get the latest tarball at + +http://academico.inf.utfsm.cl:81/~jcid/Dillo/d010a7.tgz + +(This is not a release yet; just some patches and progress trying +to overcome the CPU-hogging bug) + + +Jorge.- + + + +Re: [Dillo-dev]CPU Hogging + +From: - 2000-04-12 13:34 + +On Wed, Apr 12, 2000 at 09:12:28AM -0400, Jorge Arellano Cid wrote: +> +> Ps: If you want to get a tarball with what's currently done, let +> me know, just to put it online. + +Yes, please do. + + +-- +Rob Warren + +email: greslin@li... +homepage: http://www.iag.net/~aleris + +GXAnim: http://www.iag.net/~aleris/gxanim.html +The Canvas Project: canvas.linuxpower.org +OpenLaw DVD FAQ: http://www.cssfaq.org + + + +[Dillo-dev]CPU Hogging + +From: Jorge Arellano Cid - 2000-04-12 13:21 + +Hello list! + +Greetings to the new members, and to the old ones! + +Some news from current project-status: + +I've been working with the CPU-hogging problem, and after +fixing several things here and there (dns.c, socket.c, http.c, +IO.c, IO.h, web.c, cache.c...), it's a decision: I'll rewrite the +cache module. + +The cache module is split among several different parts in the +code, and integrated in a subtle way with some others. Getting +the idea of the data flow (and the algorithms) becomes a titanic +task, and maintenance is almost impossible. Ah, and it's broken! + +Now I'm working on it, and when its done: a new tarball will be +released. After that, we'll set dillo.so....net to be a +mirror of our main site, and I'll make a freshmeat announce "urbi +et orbi". + +The new site server is almost ready. Just need to move the +database and the bug-track engine there... + +If you feel like patching dillo, please focus on the rendering +part for now; the low level routines are under heavy +reconstruction. + + +Best regards +Jorge.- + + + +Ps: If you want to get a tarball with what's currently done, let +me know, just to put it online. +Ps2: Don't use the CVS now, it's outdated, and when we get it +sync. it will serve as a checkout only. + + + +[Dillo-dev]CPU hogging (part 1) + +From: Jorge Arellano Cid - 2000-04-05 14:27 + +Hi, + +I just fixed the short CPU hogging that happened when waiting +for a DNS query. (Look bug #50 in the bug-track). +This doesn't mean that the whole CPU hogging problem is solved. Our +mailing-list-archives-link still hogs the CPU (And forever). +I'll focus on that now. + +Jorge.- + + + +Re: [Dillo-dev]Announce + +From: - 2000-04-04 21:25 + +On Tue, Apr 04, 2000 at 02:41:45PM -0400, Jorge Arellano Cid wrote: +> [Rob said] +> > Right now I'm far more concerned about this runaway CPU usage. Dillo compiled +> > great out of the box, and it looks good and stable. But after only calling up +> > a page or two, it started grabbing 98% of my CPU. This is absolutely unacceptable. +> > +> > Does anyone have any idea what is causing this? I assume Dillo is using a +> > threading system of some kind; could this be the problem? +> +> OK, I've been workink on that. +> It is NOT the threading system! +> Actually, what causes the problem is URL redirection. If you hit a +> redirected URL, the CPU will be hogged. + +I don't buy this. I've tried calling up my own web page at: + +http://www.iag.net/~aleris + +and sometimes it causes CPU hogging, sometimes it doesn't. It doesn't seem to be +tied into the threading system at this point; I disabled threading support and +it still happens. Somewhere there is a piece of code that drops into a nearly +infinite loop or something. I suspect it is somewhere in the vicinity of the DNS +resolution code but I can't prove it yet. + + + +> +> > Before we get too deep in making it pretty, we need to improve the infrastructure. +> > The alternative is to end up with Netscape Communicator. :( +> +> Yes man, I agree. +> Have you figured out the whole mess that we had before this release? +> +> Well, technically talking I've been studying the problem and almost +> every problem comes from the IO engine change. It behaves asynchronously +> but, it was struggled-in without the minimal considerations about that +> kind of processing. I mean, several critical races were introduced and +> it was merged with the former (streamed) implementatiom. Frankly I'm not +> sure now if trying to fix it, or plainly rewriting it. + +The latter may be a better idea. This code is a mess, and we'll end up +spending more time trying to figure the code out than we will fixing it. +We should probably aim at a gradual rewrite of the browser itself before +we start shoehorning new features into the current architecture. + + +Rob Warren + +email: greslin@li... +homepage: http://www.iag.net/~aleris + +GXAnim: http://www.iag.net/~aleris/gxanim.html +The Canvas Project: canvas.linuxpower.org +OpenLaw DVD FAQ: http://www.cssfaq.org + + + +Re: [Dillo-dev]Announce + +From: - 2000-04-04 18:39 + +On Tue, Apr 04, 2000 at 02:41:45PM -0400, Jorge Arellano Cid wrote: +> +> Rob, +> +> +> > I'm getting it through Sourceforge. +> +> But you checked our site in the academico server, right? + +Yes, I have. It's just that I'm working through SF for other projects; this +is more convenient for me. + +> +> > Do me a favor; could you go ahead and +> > clear me as a developer? +> +> Sorry (my poor english), what do you mean? + +Go to Sourceforge and indicate to their systems that "Greslin" is one of +your developers. This will give me update access to the CVS tree. + + +> > Right now I'm far more concerned about this runaway CPU usage. Dillo compiled +> > great out of the box, and it looks good and stable. But after only calling up +> > a page or two, it started grabbing 98% of my CPU. This is absolutely unacceptable. +> > +> > Does anyone have any idea what is causing this? I assume Dillo is using a +> > threading system of some kind; could this be the problem? +> +> OK, I've been workink on that. +> It is NOT the threading system! +> Actually, what causes the problem is URL redirection. If you hit a +> redirected URL, the CPU will be hogged. + +I'll tinker with it when I get time. + + +-- +Rob Warren + +email: greslin@li... +homepage: http://www.iag.net/~aleris + +GXAnim: http://www.iag.net/~aleris/gxanim.html +The Canvas Project: canvas.linuxpower.org +OpenLaw DVD FAQ: http://www.cssfaq.org + + + +Re: [Dillo-dev]Announce + +From: Jorge Arellano Cid - 2000-04-04 18:33 + +Rob, + + +> I'm getting it through Sourceforge. + +But you checked our site in the academico server, right? + +> Do me a favor; could you go ahead and +> clear me as a developer? + +Sorry (my poor english), what do you mean? + +> Right now I'm far more concerned about this runaway CPU usage. Dillo compiled +> great out of the box, and it looks good and stable. But after only calling up +> a page or two, it started grabbing 98% of my CPU. This is absolutely unacceptable. +> +> Does anyone have any idea what is causing this? I assume Dillo is using a +> threading system of some kind; could this be the problem? + +OK, I've been workink on that. +It is NOT the threading system! +Actually, what causes the problem is URL redirection. If you hit a +redirected URL, the CPU will be hogged. + +> Before we get too deep in making it pretty, we need to improve the infrastructure. +> The alternative is to end up with Netscape Communicator. :( + +Yes man, I agree. +Have you figured out the whole mess that we had before this release? + +Well, technically talking I've been studying the problem and almost +every problem comes from the IO engine change. It behaves asynchronously +but, it was struggled-in without the minimal considerations about that +kind of processing. I mean, several critical races were introduced and +it was merged with the former (streamed) implementatiom. Frankly I'm not +sure now if trying to fix it, or plainly rewriting it. + +The cache system integrates with the IO and it is also obscure :-( +I still can't find a clear way of using it and handling close and abort +requests the way it should be so, basically I'm studying the code now +to try to find whether to heavily fix it or to change it. +As a matter of fact, this would not be the first module rewrite in the +project. + +If you suggest me an IRC channel now, +no problem to meet you there. + + +Jorge.- + + + +Re: [Dillo-dev]Announce + +From: - 2000-04-04 16:59 + +On Tue, Apr 04, 2000 at 09:33:08AM -0400, Jorge Arellano Cid wrote: +> +> Rob, +> +> First of all, welcome aboard! +> You were the first to answer the announce, and I already saw +> you in the mailing list! +> I know our server was down for a couple of hours (or more?), +> but it is working now! Please let me know if you were able to +> reach it. + +I'm getting it through Sourceforge. Do me a favor; could you go ahead and +clear me as a developer? + + +> > I'm a C programmer, familiar with GTK and application development. I currently +> > maintain GXAnim (GTK frontend to XAnim movie player) and am very slowly working +> > on the Canvas Project, another video-related project. In my spare time I +> > work with the Open File Sharing Initiative (napster-esque file transfer) and do +> > quite a bit of work with the Openlaw DVD forum at Harvard Law. +> +> Perfect, GUIs and some networking! +> May a suggest you take a look at Dillo widget bugs? +> We are very concerned of the small pages rendering bug. + +Right now I'm far more concerned about this runaway CPU usage. Dillo compiled +great out of the box, and it looks good and stable. But after only calling up +a page or two, it started grabbing 98% of my CPU. This is absolutely unacceptable. + +Does anyone have any idea what is causing this? I assume Dillo is using a +threading system of some kind; could this be the problem? + +Before we get too deep in making it pretty, we need to improve the infrastructure. +The alternative is to end up with Netscape Communicator. :( + + + +Rob Warren + +email: greslin@li... +homepage: http://www.iag.net/~aleris + +GXAnim: http://www.iag.net/~aleris/gxanim.html +The Canvas Project: canvas.linuxpower.org +OpenLaw DVD FAQ: http://www.cssfaq.org + + + +Re: [Dillo-dev]bug - incomplete rendering of html + +From: Jorge Arellano Cid - 2000-04-04 13:42 + +Sammy, + +On Mon, 3 Apr 2000, nightstalker wrote: + +> i have noticed something about this bug (reading small html files can +> result in incomplete displays .. workaround is to hit reload :) + +Just sometimes. You may have to resize the window or go back +and forward to fix the display. +This is a Dillo-Widget bug. +I think its due to initialization problems. If you look at it +in detail, you'll notice that sometimes, a gray square renders on +top of the page (try loading a small image for instance), and +that its height is exactly the same of the whole set of toolbars. +Some other times, small HTML pages "appear" with an upward +shift... + + +> i first ran dillo with the 'nstalkie' user who uses the Aqua gtk-theme. +> the bug occured. Then i ran dillo with the 'progs' user who +> uses the Cheese gtk-theme. The bug +> also occured BUT in a different way. i had to press reload twice in +> order to view the whole page. + +Yes, what we have here is not a single thread problem but an +asynchronous race condition. That explains the variations. If you +try it several times, with different CPU loads for instance, you +may notice diferences with the same gtk-theme. + + +Jorge.- + + + +[Dillo-dev]Re: tarball location, etc. + +From: Jorge Arellano Cid - 2000-04-04 13:42 + +James, + +On Mon, 3 Apr 2000, James McCollough wrote: + +> hey - +> +> Sourceforge has webspace for us at dillo.so....net. Could you +> send me all the files that make up the dillo website, so I can mirror +> them on so....net? + +No. :-) + +Not every file. The problem is mainly with Dillo bug-track +engine; it uses a database that's set in 'tonatiuh' server, and I +want to keep it there (Is faster an easier to administrate). +Well, there're several other pages that I can send you, just +let me make absolute links for them. +The other important fact is that if we have sourceforge +mirroring the site, you (or someone else) has to do the sync. +work... + +> I will also move the tarball there shortly. + +By now, you already did it; I checked all the links. +Thanks. +(Don't erase download.so....net/dillo/dillo-0.1.0.tar.gz) + +> By the I really like the new release. +> It is very stable. + +Good!!! +(Stabilization is one of our main concerns.) + +> I am also going to update the CVS shortly. + +Don't you hurry. +I'm thinking of setting it locally in 'huallepen'. +Why? +Because so....net is a very slow link form here, the CVS +doesn't generate a big network load, and I have an exclusive +machine to put it on! + +Jorge.- + + + +Re: [Dillo-dev]Announce + +From: Jorge Arellano Cid - 2000-04-04 13:42 + +Rob, + +First of all, welcome aboard! +You were the first to answer the announce, and I already saw +you in the mailing list! +I know our server was down for a couple of hours (or more?), +but it is working now! Please let me know if you were able to +reach it. + +> I just saw your announcement on gtk-app-devel. All I can say is, good. It's +> good to know that someone's picked up gzilla from the dustbin; I hate to think +> that the only modern browsers we have for Linux are commercial ones. + +Well, our beloved Dillo is far away from challenging those big +ones, but its speed and anti-bloat design are addictive! +(We'll try to make it render the whole HTML 4.0 before thinking +of extending it. And when I say "render HTML 4.0", I mean to have +the info displayed in a suitable way.) + +> I'm a C programmer, familiar with GTK and application development. I currently +> maintain GXAnim (GTK frontend to XAnim movie player) and am very slowly working +> on the Canvas Project, another video-related project. In my spare time I +> work with the Open File Sharing Initiative (napster-esque file transfer) and do +> quite a bit of work with the Openlaw DVD forum at Harvard Law. + +Perfect, GUIs and some networking! +May a suggest you take a look at Dillo widget bugs? +We are very concerned of the small pages rendering bug. + +> Anyway, I don't know how much time I'll be able to devote here, but I'll put +> my two bits in where I can and throw a piece of code out every so often. Do +> you guys have a CVS of your current source? (I assume so.. you're on +> Sourceforge, right?) + +Actually we have, but I'll try to set it up on another server, +not sourceforge (We are half sourceforgers) +When the CVS is set, I'll let you all know. It will work only +as a checkout in the beginning... + + + +Jorge.- + + + +Re: [Dillo-dev]problem with urls. + +From: Jorge Arellano Cid - 2000-04-04 13:42 + +Sammy, + + +On Sun, 2 Apr 2000, nightstalker wrote: + +> hi, +> +> this is a minor thingie ... +> when you enter an url like this: +> http://www.skoardy.demon.co.uk/rlnews +> dillo must put a '/' behind this .. i have already found the place in +> the code +> where it should happen, but i was thinking : + +Actually that happens! +Look at the VT screen behind Dillo (Nav_open_url) and you'll +see the URL change. + +> how can you know this is a directory ? + +There's no way, that I know, to know that in advance. +If you have " 'hi' can be either a file or a +directory. + +> i'm thinking of this : +> i can add a test to see if there are any '.' or '?' in the tail (in this +> example /rlnews) (the ? is for queries which can be without +> a dot but may not get a trailing '/' for example : +> http://www.altavista.com/cgi-bin/query?pg=q&sc=on&hl=on&q=dillo&kl=XX&stype=stext + +Sure, there're those URLs too. +I think that a good guess can be done using the last filename: +If it has a '.', most probably it's a dir! +You have to check it for POST or GET or whatever before making +the gess though. +The sure way to proceed is to check the RFC. + +> is it possible for a http address to have a '.' in the directory name ? + +Yes. + + +Jorge.- + + + +Re: [Dillo-dev]Announce + +From: - 2000-04-03 21:44 + +On Mon, Apr 03, 2000 at 04:56:52PM -0400, Jorge Arellano Cid wrote: +> +> Ok, I made the announcement to gtk app devel list, +> Does anyone feel like announcing it to sourceforge news? James? Luca? +> +> Ah, also updated the website. +> +> Jorge.- + +Hey ho. + +I just saw your announcement on gtk-app-devel. All I can say is, good. It's +good to know that someone's picked up gzilla from the dustbin; I hate to think +that the only modern browsers we have for Linux are commercial ones. + +I'm a C programmer, familiar with GTK and application development. I currently +maintain GXAnim (GTK frontend to XAnim movie player) and am very slowly working +on the Canvas Project, another video-related project. In my spare time I +work with the Open File Sharing Initiative (napster-esque file transfer) and do +quite a bit of work with the Openlaw DVD forum at Harvard Law. + +Anyway, I don't know how much time I'll be able to devote here, but I'll put +my two bits in where I can and throw a piece of code out every so often. Do +you guys have a CVS of your current source? (I assume so.. you're on +Sourceforge, right?) + + +Rob Warren + +email: greslin@li... +homepage: http://www.iag.net/~aleris + +GXAnim: http://www.iag.net/~aleris/gxanim.html +The Canvas Project: canvas.linuxpower.org +OpenLaw DVD FAQ: http://www.cssfaq.org + + + +[Dillo-dev]Announce + +From: Jorge Arellano Cid - 2000-04-03 21:18 + +Ok, I made the announcement to gtk app devel list, +Does anyone feel like announcing it to sourceforge news? James? Luca? + +Ah, also updated the website. + +Jorge.- + + +-------------------- +gtk announce follows +-------------------- +Hi there, + +I only hope this to be the right place for this announcement; please +don't suggest freshmeat cause Dillo is still alpha code. + +Dillo is a gtk+based web browser that's very fast, lean and extensible. +It has its own HTML parsing routines, is written completely in C and the +tarball is just 200Kb! (The stripped binary is also 200Kb). +There's no support for Java, javascript. + +We are in need of developers; those of you who feel interested in +this project, or just wnat more info, take a look at + +http://academico.inf.utfsm.cl:81/~jcid/Dillo/project.html + +you'll find everything there. + + +Jorge.- +Dillo project maintainer + + +Ps: Dillo is GPLed! + + + +Re: [Dillo-dev]Developer release + +From: Jorge Arellano Cid - 2000-04-03 13:21 + +Hi, + +On Sun, 2 Apr 2000, nightstalker wrote: + +> Jorge Arellano Cid wrote: +> +> > Hi everyone! +> > +> > Today dillo-0.1.0.tar.gz is ready for download. It will be our +> > first public developer release! +> > +> +> cool ! +> +> > +> > When James finish setting it to on the sourceforge ftp server, +> > I'll add a download link to the home page, announce it to the gtk +> > devel mailing list, and it will be public! +> > +> +> we can also announce it on freshmeat (freshmeat.net) + +Yes, we can, but later... +Why? + +1.- Because I need to address server traffic concerns. +Currently the source is in the academico server and also at +ftp://ftp.so....net/pub/sourceforge/dillo/dillo-0.1.0.tar.gz +The first one is not able to handle a big load, as what could +be generated by a freshmeat announce, and the second one is very +slow and unreliable. This week I'll set up a new server, and +maybe put the source on a ftp port with a maximum concurrent +connection limit. +The best setting (IMHO) is to have dillo source at: +http://dillo.so....net/dillo-0.1.0.tar.gz +and everything else in the new server. + +2.- Because we need more developers, and the gtk mailing list +is a better place to find gtk skilled guys. The freshmeat list +has a broader range, and our release is not ready for users yet. +(Anyway, if the gtk-mailing-list announce fails to bring new +devels. to the project, a freshmeat one will follow quickly!) + + +Jorge.- + + +Ps: James, would you mind setting the +http://dillo.so....net/dillo-0.1.0.tar.gz URL? + + + +[Dillo-dev]bug - incomplete rendering of html + +From: nightstalker - 2000-04-03 00:02 + +i have noticed something about this bug (reading small html files can +result +in incomplete displays .. workaround is to hit reload :) + +i first ran dillo with the 'nstalkie' user who uses the Aqua gtk-theme. +the bug +occured. +then i ran dillo with the 'progs' user who uses the Cheese gtk-theme. +the bug +also occured BUT in a different way. i had to press reload twice in +order to +view the whole page. + +this bug is getting weirder and weirder :) + +ns + + + +[Dillo-dev]problem with urls. + +From: nightstalker - 2000-04-02 23:15 + +hi, + +this is a minor thingie ... +when you enter an url like this: +http://www.skoardy.demon.co.uk/rlnews +dillo must put a '/' behind this .. i have already found the place in +the code +where it should happen, but i was thinking : + +how can you know this is a directory ? i'm thinking of this : +i can add a test to see if there are any '.' or '?' in the tail (in this +example +/rlnews) (the ? is for queries which can be without a dot but may not +get a +trailing '/' for example : +http://www.altavista.com/cgi-bin/query?pg=q&sc=on&hl=on&q=dillo&kl=XX&stype=stext + +is it possible for a http address to have a '.' in the directory name ? + +ns. + +ps: yes i'm a roguelike fan :) + + + +Re: [Dillo-dev]Developer release + +From: nightstalker - 2000-04-02 21:58 + +Jorge Arellano Cid wrote: + +> Hi everyone! +> +> Today dillo-0.1.0.tar.gz is ready for download. It will be our +> first public developer release! +> + +cool ! + +> +> When James finish setting it to on the sourceforge ftp server, +> I'll add a download link to the home page, announce it to the gtk +> devel mailing list, and it will be public! +> + +we can also announce it on freshmeat (freshmeat.net) + +> +> Comments are welcomed. +> +> Jorge.- +> +> Pd: Haven't got any feedback on the former release yet :-| +> + +i haven't really tried the newest release yet .. (i'll try 0.1.0) +all i saw was that it was good :) + +ns. + + diff --git a/old/oldmail/200005.txt b/old/oldmail/200005.txt new file mode 100644 index 0000000..a2076f2 --- /dev/null +++ b/old/oldmail/200005.txt @@ -0,0 +1,388 @@ +Re: [Dillo-dev]Bug 35... fixed! (I hope) + +From: Jorge Arellano Cid - 2000-05-29 01:48 + +Andrew, + +On Thu, 25 May 2000 andrew@ma... wrote: + +> I think I finally nailed that nasty bug 35. From extensive g_prints, I +> discovered what was going on: +> +> ... +> +> Sorry, that wasn't very clear. I hope you can sort of follow what I'm +> saying. + +Thank you very much for the explanation. Although I haven't got +the time (yet) to analyze it in full detail, it is and will be of +great help. + +When dealing with the new cache scheme (and formerly with the +dicache and the image resize), I faced similar problems. It seems +that a state machine is a good way to solve that nasty race +conditions, but I prefer a flag scheme, just because it is more +flexible and easier to implement. Maybe that'd become the final +fix of it... + +> Hope the change works out. + +I've been stress testing the patch, it works nearly 95% of the +time, not perfect, but definitively better than what we had. +It *earned* its way into the code! + +Once again, thank you very much. + + +Jorge.- + + +Ps: Expect dillo-0.2.0 release near friday. + + + +[Dillo-dev]Bug 35... fixed! (I hope) + +From: - 2000-05-25 23:02 + +Attachments: Message as HTML + +I think I finally nailed that nasty bug 35. From extensive g_prints, I +discovered what was going on: + +1) Dillo makes a new browser, and a GtkDwView structure some time later. +This starts out with a visible region of (0,0) to (101,101) for its +container. +2) Shortly thereafter, dw_gtk_view_size_allocate is called to make the +viewport the correct size. However, the container's visible region only +gets updated if the widget is realized, which it is not (yet). +3) Meanwhile, the first paint requests have been called, and dillo begins +to start the drawing functions. All rectangles get clipped to the +"visible" region of (0,0)-(101,101). +4) Finally (a fraction of a second later), the window shows up and the +viewport is realized. But it's too late. The drawing is done on the old +visible rectangle. +5) Right _after_ this happens, dw_gtk_view_size_allocate is called again, +with a realized widget. The visible rectangle of the viewport's container +is properly adjusted, and things work from here on out. + +Sorry, that wasn't very clear. I hope you can sort of follow what I'm +saying. + +Anyway, the fix I came up with involves changing the code in +Dw_gtk_view_size_allocate so that dw_view->dw_container->visible is +updated regardless of whether the widget is realized or not. I don't think +this should create any problem as there is already a check in place to +make sure the widget isn't null. The diff is attached. + +The only other way around this that I saw was to change the structure of +dillo so that the drawing functions only got called after the window was +visible, but this might have taken a total rewrite of many of the +functions. + +Hope the change works out. + +-Andrew + + + +Re: [Dillo-dev]Very close to a new release + +From: - 2000-05-24 23:03 + +On Wed, 24 May 2000, Jorge Arellano Cid wrote: + +> +> Andrew: +> +> It would be very nice to integrate a fix for bug #35 in the new +> release; Any progress with that? +> + +Well, progress but no fix. My time just sort of disappeared. (I joined the +project during a time of low activity in my other projects, which +subsequently picked up again. Figures.) + +Anyway, I'll look back at it. I think it could be as simple as setting the +visible rectangle of the viewport to be the size of the window rather than +the default 101x101. I just haven't nailed down the best way to do that. + +There will be a fix, but it might come after the initial release. + +-Andrew + + + +[Dillo-dev]Very close to a new release + +From: Jorge Arellano Cid - 2000-05-24 21:50 + +Hi! + +The traffic here has been very low, but Dillo survived a major +architecture change; the new release will be a half-new browser! + +In fact, all the IO engine and http stuff was rewritten from +scratch, and even the way data is passed to rendering routines +changed. +Mainly this means that the cache integrates with the IO engine +and that the rest of the browser deals with the cache part only +(it works as an abstraction layer). + +Although the system remains very complex, it is much easier to +understand, extend and change. + +THIS IS NOT VAPORWARE!!! +It is running NOW! + +I'm just polishing raw edges to follow the "evolving" model we +use, and accordingly, to release a better browser. +Primary tests had gone very well. (Except for a problem with +redhat and its socket handling --Don't worry, its OK now). + + + +Andrew: + +It would be very nice to integrate a fix for bug #35 in the new +release; Any progress with that? + + +Mark: + +Please get a user account on sourceforge, and send me your login +(UID) to allow you workout the web site. + + +James: + +Are you getting this message? +You're email address seems not to be working... + + +Everyone: + +Any feedback is welcome. + + +Jorge.- + + + +Re: [Dillo-dev]Bug 35 progess + +From: - 2000-05-10 14:25 + +On Tue, 9 May 2000, Jorge Arellano Cid wrote: + +> +> Andrew, +> +> On Fri, 21 Sep 1956 andrew@ma... wrote: +> Note the date!!! +> I know I'm a little late answering this one! ;-) + +Sorry, that should be fixed now... + +> > I turned on verbose messaging and added a lot of g_print's of my own so I +> > could get a feel for what's going on. First of all, on my Intel box +> > running GTK+ 1.2.3, I noticed that creating the window never calls +> > size_allocate, but it does show all the widgets, so the first time around, +> > the sizes are things like (0,0) to (10, 65533), negative numbers, and +> > other crazy stuff. This doesn't happen on GTK+ 1.2.6 on PowerPC. This is +> > undoubtedly a GTK flaw, not a Dillo one, and I think it's unrelated to the +> > problem. +> +> Good! +> That's the kind of work we need. +> +> > ... I think the fundamental problem is in +> > dw_gtk_view.c in the a_Dw_gtk_view_new function. It sets the visible +> > rectangle as (0,0)-(101,101) with a "todo"comment to make it reflect the +> > widget size. (101,101) is coincidentally where the drawing gets cut off on +> > the Power Mac. +> > +> > When I hit reload, it gets updated, and I haven't traced the code to +> > figure out where or how that happens. +> +> Well, not having documentation about Dillo widget is one of our +> problems. I'd very much like to have that written; but priorities +> had kept me away from that... +> +> > I figure that the best fix is to make the visible rectangle update right +> > away (I don't know how I'll do that yet). Or is that just covering the +> > symptoms without fixing the problem? +> +> Sorry, but I can't tell you if that's THE right fix. Probably +> what needs to be done is to find out how the update is triggered +> (and carried out) after hitting the reload button. And noting why +> sometimes a page renders and some others not; due to a race +> condition on a gtk idle function? Bad init values? +> ... and after that, to decide if that's the right patch. +> +> Anyway, if it fixes the problem, we can make it into our code +> with a "todo: assert this is the right way to do this" tag on it +> :) +> +> Any new or progress notice is welcomed + +I'll see what I can do. Maybe I'll post some sort of log here if I get +stuck again. Right now I'm just fighting lack of time. + +I think the reason that sometimes it gets rendered and sometimes not has +to do with the rect that gets sent to the draw function-- it gets clipped +to the supposed "visible" region of the dillo widget, which, at least the +first time, isn't correct. + +-Andrew + + + +Re: [Dillo-dev]Bug 35 progess + +From: Jorge Arellano Cid - 2000-05-10 03:15 + +Andrew, + +On Fri, 21 Sep 1956 andrew@ma... wrote: +Note the date!!! +I know I'm a little late answering this one! ;-) + + +> I turned on verbose messaging and added a lot of g_print's of my own so I +> could get a feel for what's going on. First of all, on my Intel box +> running GTK+ 1.2.3, I noticed that creating the window never calls +> size_allocate, but it does show all the widgets, so the first time around, +> the sizes are things like (0,0) to (10, 65533), negative numbers, and +> other crazy stuff. This doesn't happen on GTK+ 1.2.6 on PowerPC. This is +> undoubtedly a GTK flaw, not a Dillo one, and I think it's unrelated to the +> problem. + +Good! +That's the kind of work we need. + +> ... I think the fundamental problem is in +> dw_gtk_view.c in the a_Dw_gtk_view_new function. It sets the visible +> rectangle as (0,0)-(101,101) with a "todo"comment to make it reflect the +> widget size. (101,101) is coincidentally where the drawing gets cut off on +> the Power Mac. +> +> When I hit reload, it gets updated, and I haven't traced the code to +> figure out where or how that happens. + +Well, not having documentation about Dillo widget is one of our +problems. I'd very much like to have that written; but priorities +had kept me away from that... + +> I figure that the best fix is to make the visible rectangle update right +> away (I don't know how I'll do that yet). Or is that just covering the +> symptoms without fixing the problem? + +Sorry, but I can't tell you if that's THE right fix. Probably +what needs to be done is to find out how the update is triggered +(and carried out) after hitting the reload button. And noting why +sometimes a page renders and some others not; due to a race +condition on a gtk idle function? Bad init values? +... and after that, to decide if that's the right patch. + +Anyway, if it fixes the problem, we can make it into our code +with a "todo: assert this is the right way to do this" tag on it +:) + +Any new or progress notice is welcomed +Good luck! +Jorge.- + + + +Re: [Dillo-dev]I need help :( + +From: Jorge Arellano Cid - 2000-05-06 02:04 + +Hi, + +On Wed, 3 May 2000, Luca Rota wrote: + +> I've some problem so I can't work on dillo awhile. +> I've the patch for a not yet working preferences gui, so if someone woulds work +> on it, please let me know. + +I would like the preferences stuff to be worked out as a +plugin. I mean something like "dillo:/preferences". It would be +easier to maintain and that way we keep the core small. +As a matter of fact, the bookmarks can also be implemented that +way. + +Jorge.- + + + +[Dillo-dev]Bug 35 progess + +From: - 2000-05-05 18:23 + +OK, I'm busy trying to track down the source of bug 35 (screen not drawing +properly the first time), and I've found some interesting things in the +process. + +I turned on verbose messaging and added a lot of g_print's of my own so I +could get a feel for what's going on. First of all, on my Intel box +running GTK+ 1.2.3, I noticed that creating the window never calls +size_allocate, but it does show all the widgets, so the first time around, +the sizes are things like (0,0) to (10, 65533), negative numbers, and +other crazy stuff. This doesn't happen on GTK+ 1.2.6 on PowerPC. This is +undoubtedly a GTK flaw, not a Dillo one, and I think it's unrelated to the +problem. + +On my Intel box, the page draws correctly except for the hr tags. I +haven't figured that out yet. On the Power Mac, it only draws a part of +the screen until I hit reload. I think the fundamental problem is in +dw_gtk_view.c in the a_Dw_gtk_view_new function. It sets the visible +rectangle as (0,0)-(101,101) with a "todo"comment to make it reflect the +widget size. (101,101) is coincidentally where the drawing gets cut off on +the Power Mac. + +When I hit reload, it gets updated, and I haven't traced the code to +figure out where or how that happens. + +I figure that the best fix is to make the visible rectangle update right +away (I don't know how I'll do that yet). Or is that just covering the +symptoms without fixing the problem? + +-Andrew + + + +[Dillo-dev]I need help :( + +From: Luca Rota - 2000-05-03 13:35 + +Hi, + +I've some problem so I can't work on dillo awhile. +I've the patch for a not yet working preferences gui, so if someone woulds work +on it, please let me know. + +Ciao, +Luca + + + +[Dillo-dev]ematic mail + +From: Jorge Arellano Cid - 2000-05-02 02:03 + +Hi there! + +I received mail from Mark, Andrew, and some time ago from James +in my ematic.com address. In fact I receive Ok from several other +places, and will assume it works right unless someone here tells +me it failed. + +Thanks +Jorge.- + + +Ps: Send failure notices to jcid@em... + + diff --git a/old/oldmail/200006.txt b/old/oldmail/200006.txt new file mode 100644 index 0000000..1ab1ebf --- /dev/null +++ b/old/oldmail/200006.txt @@ -0,0 +1,309 @@ +[Dillo-dev]progress + +From: Jorge Arellano Cid - 2000-06-28 17:45 + +Hi there! + +We are getting closer to a new release due to several changes +in the code. Current Changelog looks like this: + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +dillo-0.2.2 [July ?, 2000] + +- * Added a gtk_window_set_wmclass to all windows to prevent dialogs +from having the same size as the main window. (Ex: with Sawfish) +Patch Jörgen Viksell +- * Fixed a segfault when calling "about:" method +Patch: Dominic Wong +- * Added an option to force dillorc-defined colors (Try it with slashdot!) +* Fixed display of encoded-URL-links on the status bar +Patches: Adam Sampson +- * Removed several compiler dependencies +(detected with lcc on a 64 bit machine) +* Modified mime.c and Url.c to use list.h, and eliminated hdlr.c +* Standarized unsigned types to glib all around the code +* Added some includes for libc5 compatibility +* Modified IO_callback to avoid a CPU-hog (it happened in some systems). +* Fixed a bug that added a trailing ampersand to GET and POST queries. +* FIxed attribute parsing. It had nasty side effects; as providing +wrong attribute values to POST and GET methods. +* Joined Url.c and url.c into a single module. +* Reimplemented URL resolving functions. +* Implemented a new parser for "file:" URLs (Try "file:" & "file:."). +Patches: Jorge Arellano Cid +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + +If you read it carefully, you'll notice several improvements, +most notably: + +- POST & GET work better (google search is working!). +- "file:" URLs got better handled. +- slashdot is readable. +- The code got more "portable" and stable. + + +I'd like to include Jörgen patches too (if they get finished): + +> I have been working on getting checkbuttons and radiobuttons to render +> properly, and it works now. Strangely enough it works when you call +> gtk_toggle_button_set_mode(GTK_TOGGLE_BUTTON(widget), FALSE), even though +> this is supposed to be set by default... + +Maybe due to a lack of a window for the button widget. +This happened with the horizontal ruler, and the first attempt +to fix it, by packing it into an event box, worked OK. +I'm not sure though, just a thing to check. + +> What bugs me now is that radio buttons appears as squares instead of +> diamond-shaped. +> I also worked on the SELECT stuff (width and height of the clist widget) +> which now seems to work. + +If you finish them please let me know. + + +- o - + +Dominic asks: + +> I have some questions about dillo. I find one dillo task in the task list +> when open nothing. But if I open a web page, one more dillo appear in my task +> list. Thus, two dillo in the task list. With top, I find both of them +> consume the same memory size. Could you tell me why? Since netscape becomes 4 +> when a web page is opened, and I wonder why it happened. + +Well, that's due to threaded code (pthreads). +When dillo starts, there's just a single thread running (the +main thread). When another thread is spawned for the first time, +(due to a DNS, or local file request), TWO more threads get +running, one for the thread scheduler and other for the spawned +process. When the spawned one finishes, the thread manager +remains; if you 'ps aux | grep dillo', you'll see two processes +that consume the same memory size but THAT'S NOT TRUE!!! +Pthreads are light weight processes that run using the same +memory space as the father (one of the advantages over fork). + + +- o - + +CscHTML: + +Certainly to be taken into account. +When I first downloaded it, found almost no documentation for +it, appart from 350Kb of code and library dependencies. + +Haven't tested the speed yet. + +The biggest concern is the cost of making the widget change, +and the loose of control over the rendering. Currently we have a +widget set that needs moderate work to start handling tables (and +that's lean, fast and already integrated to our browser). + +I think if we manage to provide a basic TABLE facility with Dw, +developers will start to work together improving it. The +advantage of having small, documented code is a nicer learning +curve that lets developers jump-in quickly. +BTW our main documentation fault is on Dw (dillo widget); any +contribution will be highly appreciated. :-) + +On the other hand, if we fail to improve Dw, the change is +almost forced (if possible). + +This remains an open issue. + + +Jorge.- + +Ps: Thanks for reading this far. +Ps2: Jörgen, I'll send you an email to your hotmail address, at +the same time I send this one to the list, please let me +know if you receive it (I've had problems with hotmail.com). + + + +[Dillo-dev]CSCHTML widget + +From: - 2000-06-26 18:00 + +Check this out +http://www.cscmail.net/cschtml/ + +this appears to be a GTK widget with _all_ html tags. I haven't done +extensive research into this, but this could be huge. It may be worth +while to look into this. + +-Mark + +"You can't get a blue screen on a black and white monitor." + + + +[Dillo-dev]form fixes + +From: Jörgen Viksell - 2000-06-25 18:11 + +Hi! + +I have been working on getting checkbuttons and radiobuttons to render +properly, and it works now. Strangely enough it works when you call +gtk_toggle_button_set_mode(GTK_TOGGLE_BUTTON(widget), FALSE), even though +this is supposed to be set by default... +What bugs me now is that radio buttons appears as squares instead of +diamond-shaped. + +I also worked on the SELECT stuff (width and height of the clist widget) +which now seems to work. + +The patch can be found here: +http://hem.passagen.se/vsksga/patches/patch-0.2.1-form_fixes + +I would appreciate if someone could try it out. And maybe fix the bugs =) + +// Jörgen +________________________________________________________________________ +Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com + + + +[Dillo-dev]ematic.com + +From: Jorge Arellano Cid - 2000-06-21 02:37 + +Hi everyone! + + +First, I want to welcome every new member of this list. + +I'm eager to "hear" your impressions and comments on dillo but +it seems that the ematic server went down the hard way, and I +haven't received mail since early Jun 18. So please, if you had +sent me mail, please resend it to jcid@ma.... + +We have new patches! I've also found a couple of bugs that +will be nailed down pretty soon. + + +regards +Jorge.- + + + +-- + + + +[Dillo-dev]dillo-0.2.1 + +From: Jorge Arellano Cid - 2000-06-17 18:09 + +Hi there! + +A lot of water went down the bridge! +Just check our new release (and website) at: +http://dillo.so....net/ + +(You'll find all the info there) + +Jorge.- +-- + + + +Re: [Dillo-dev]New release + +From: Jorge Arellano Cid - 2000-06-07 14:21 + +Andrew: + +> The new release seems to work well. Thanks! + +Good! +It was tested on Slackware 7.0, Slackware 3.6 libc5 (with a few +changes), Redhat 6.2 and Suse. + +It behaves very stable here and I hope it works the same for +everyone. + +> Is it just me or has bug 9 disappeared? (The one with mishandled # tags). +> I browsed around a page with them in it and I never saw page.html#a#b or +> anything like that. + +No, the bug IS there; it just hides! :) + +If you browse a page that has a # anchor to another page, +there's no problem, but if the # refers to the same page -> BUG. + +Test this one: http://dillo.inf.utfsm.cl/test/spg.htm + +> And, for that matter, how many of those other bugs have been fixed in +> Dillo 0.2.0 without the database being updated? + +Not a single one. The database reflects current state. + +I left bug #35 there cause the BUG remains there; mitigated but +still alive... + + +> Thanks, + +You're welcome. + + +Jorge.- + + +Pd: Updated "--" to "McPherson" + + + +Re: [Dillo-dev]New release + +From: Andrew McPherson - 2000-06-07 00:19 + +The new release seems to work well. Thanks! + +Is it just me or has bug 9 disappeared? (The one with mishandled # tags). +I browsed around a page with them in it and I never saw page.html#a#b or +anything like that. Did somebody fix that without updating the bug-track +engine? + +And, for that matter, how many of those other bugs have been fixed in +Dillo 0.2.0 without the database being updated? + +Thanks, + +-Andrew + + + +[Dillo-dev]New release + +From: Jorge Arellano Cid - 2000-06-03 03:16 + +Hi! + +Its been a long long time since the last release (two months) +and I want to apologize for this. Although work had been hectic +on my side, I couldn't make it in less time... + +Well, an evolving model, and always releasing a better browser +are good rules to follow. + +The good news is that we have a HALF-NEW browser!!! +(Check the Changelog.who for details) + +I hope you enjoy this version. +Feedback is encouraged.- + + +Jorge.- + + +Pd : I'll update the web site ASAP (maybe on Monday). + +Pd2: Luca: +I didn't include your justification patch in this version +cause it broke the rendering of some pages. + + diff --git a/old/oldmail/200007.txt b/old/oldmail/200007.txt new file mode 100644 index 0000000..6d74355 --- /dev/null +++ b/old/oldmail/200007.txt @@ -0,0 +1,1378 @@ +Re: [Dillo-dev]Bug #4, #62, #63 + +From: Seth de l'Isle - 2000-07-31 20:08 + +On Mon, Jul 31, 2000 at 11:47:36PM +0900, Eric GAUDET wrote: +> Le 29-Jul-2000, on m'a dit : + +> +> > Bug #63 (Segfault when you click enter in location field): I can't reproduce +> > it. + +I found that bug running on an older slack install, when I tried to reproduce +it on a newer mandrake install everything seemed fine. + +> > +> +> Me neither + + + +-- -- -- -- -- -- -- -- -- -- -- --. +,_ /) (\ _, Seth de l'Isle, President | +>> <<,_,>> << Arctic Fox Technology Inc. | +// _0.-.0_ \\ PO Box 70468 | +\'._/ \_.'/ Fairbanks, AK 99707 | +'-.\.--.--./.-' (907) 452-1199 | +__/ : :Y: : \ _ http://www.ubertechnique.com | +';, .-(_| : : | : : |_)-. ,:' -- -- -- -- -- -- -- -- --' +\\/.' |: : :|: : :| `.\// +(/ |: : :|: : :| \) +|: : :|: : :; +/\ : : | : : /\ +(_/'.: :.: :.'\_) +\\ `""`""` // +jgs \\ // +':. .:' + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Eric GAUDET - 2000-07-31 14:48 + +Le 29-Jul-2000, on m'a dit : +> Hello World! +> +> I've some questions on bug in subject! +> +> Bug #4 (images as white square): I can reproduce it only with PNG. Gif and +> jpeg works just fine. Maybe a png specific problem ?!? +> + +I noticed that too. I've been investigating dillo's source, and what I can tell +so far is it seems to be a libpng bug : in png.c, function Png_datarow_callback +calls the libpng function : +png_progressive_combine_row(png_ptr, png->row_pointers[row_num], new_row); +The 3 *same* parameters, can either build a (buggy) white row or the correct +image row. +I can't see anything wrong with png_ptr, which is pretty much always handled by +libpng functions. +I noticed the bug is much more frequent when there is several images : I wonder +if my libpng is compiled reentrant. +I'm using libpng-1.0.8-1mdk.rpm +Does anybody have a system where this bug never occurs ? If so, please tell us +your libpng version. + +> Bug #63 (Segfault when you click enter in location field): I can't reproduce +> it. +> + +Me neither + +---------------------------------- +Eric GAUDET +Le 31-Jul-2000 a 21:59:21 +---------------------------------- + + + +[Dillo-dev]Bug #4, #62, #63 + +From: Luca Rota - 2000-07-31 09:39 + +Hello World! + +I've some questions on bug in subject! + +Bug #4 (images as white square): I can reproduce it only with PNG. Gif and +jpeg works just fine. Maybe a png specific problem ?!? + +Bug #62 (
tag's width problem): Dw_hruler_size_nego_y() (file dw_hrule.c) +is commented. But that code seem ok! It works! Why is commented? + +Bug #63 (Segfault when you click enter in location field): I can't reproduce it. + +Ciao, +Luca + + + +[Dillo-dev]Html test suite + +From: Eric GAUDET - 2000-07-30 16:34 + +I've done some pages to begin with : basic html structure, colors. I'm +currently finishing the characters page. +But I'm not sure what's urgent to do next. + +What html specs do you want me to build test pages for (high and medium +priority) ? Do you want first (only ?) well-formated documents, or do you need +faulty documents too (missing, misplaced or incorrect tags) + +Here is a list topics we can test : +- basic html structure +- characters +- Text rendering (style, colour, fonts) +- Text formating (paragraphs) +- Images +- language (encoding, direction, AFAIK gtk+ can't print 16bits chars) +- lists +- links +- forms +- tables +- frames +- objets +- style sheets + +Eric + +PS: Do we aim for html 3 or html 4 compliance ? + +---------------------------------- +Eric GAUDET +Le 31-Jul-2000 a 01:09:08 +---------------------------------- + + + +RE: [Dillo-dev]Re: Eric + +From: Jorge Arellano Cid - 2000-07-29 00:47 + +Eric, + +> Jorge, +> I tryied 3 different email addresses yo mail you, all rejected. Where can I +> send you the screenshots ? + +I got your emails. As a matter of fact, you can browse the +screenshots in our site ;-) + +Thanks a lot Eric +Jorge.- + + +Ps: I've got some unanswered emails still... I've been very busy, +but that's good! + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Jorge Arellano Cid - 2000-07-29 00:47 + +Sebastian, + +> > Jorge Arellano Cid wrote: +> > > [...] +> > > Ah, let me know if you'd prefer to continue working the patch +> > > after next release (having the docs and new code), or to try to +> > > push it into dillo 0.2.3. +> > +> > Docs is currently not the matter (unless I would find out a much more +> > elegant solution after I've better understood the code ;-), but there is +> > still a bit to do, so it depends on when you are planning to release +> > version 0.2.3. +> +> Perhaps, it *is* a matter. I have unterstood Dw not well, but mostly +> well enough for my problem. But there are some other problems. + +I think it's a matter cause it doesn't work as expected. Some +parts are missing, some other are incomplete, and some have +workaround tweaks. +For instance, when Jörgen fixed the checkboxes, his code was +right, but it didn't work because button widgets were not +receiving the expose events. + +If the "scroller" and "view" code was right, maybe I'd suggest +you to try a patch based on "changed" and "value changed" +signals, but that code is a mess! + +> A current problem is: When do the pixel positions of anchors definitely +> have their correct values? + +When all the previous images sizes are known. This is not +deterministic, and heavily depends on network traffic. Even more, +if we add more resizing widgets, those should be accounted too. + +> They sometimes must be corrected (e. g. +> because the size of an image was unknown before), + +Yes. + +> so the scrolling +> position sometimes changes in my timeout function, which does therefor +> not stop after this was successful (otherwise you have often wrong +> scroller positions), but first when a flag in DwScroller is set. +> +> Where should this flag be set? I only tried Html_close, and I get +> *allways* the correct scroller position (although I did not expect +> that), but often the timeout function continues. (Even when not the +> two cases are given: 1. no HTML, 2. the transmission was canceled.) + +I see several things here: + +- The timeout function should not override user scrolling +(i.e. if the user scrolls the page with the mouse). +- Html_close can't be trusted to happen. +- Image reception can't be trusted. +- It would be nice to have a #anchor display function that +doesn't get fooled with page resizes (as we're trying). + +Maybe, if the timeout function validates itself, the problem can +be addressed in a simpler way. I mean, let the timeout function +start, poll until it finds the #anchor, then set its AnchorFound +flag and to continue correcting the value until: + +- #anchor is not found anymore or +- user scrolls the page (either with keyboard or with mouse) + +When one of those happens, it removes itself. + +I know this is not perfect, but you'll find a way! ;) + + +Jorge.- + +Ps: It took some time to build this hint. I hope it helps! + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Sebastian Geerken - 2000-07-28 13:27 + +I wrote: +> [...] +> Jorge Arellano Cid wrote: +> > [...] +> > Ah, let me know if you'd prefer to continue working the patch +> > after next release (having the docs and new code), or to try to +> > push it into dillo 0.2.3. +> +> Docs is currently not the matter (unless I would find out a much more +> elegant solution after I've better understood the code ;-), but there is +> still a bit to do, so it depends on when you are planning to release +> version 0.2.3. + +Perhaps, it *is* a matter. I have unterstood Dw not well, but mostly +well enough for my problem. But there are some other problems. + +A current problem is: When do the pixel positions of anchors definitely +have their correct values? They sometimes must be corrected (e. g. +because the size of an image was unknown before), so the scrolling +position sometimes changes in my timeout function, which does therefor +not stop after this was successful (otherwise you have often wrong +scroller positions), but first when a flag in DwScroller is set. + +Where should this flag be set? I only tried Html_close, and I get +*allways* the correct scroller position (although I did not expect +that), but often the timeout function continues. (Even when not the +two cases are given: 1. no HTML, 2. the transmission was canceled.) + +I tried to traceback Html_close in gdb, but for my taste there are to +much void pointers ;-) + +Sebastian. + + + +RE: [Dillo-dev]Re: Eric + +From: Eric GAUDET - 2000-07-28 04:38 + +Jorge, +I tryied 3 different email addresses yo mail you, all rejected. Where can I +send you the screenshots ? + +---------------------------------- +Eric GAUDET +Le 28-Jul-2000 a 13:36:08 +---------------------------------- + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Sebastian Geerken - 2000-07-27 16:29 + +Hi, Jorge! + +Jorge Arellano Cid wrote: +> [...] +> > Currently, I store the requested anchor (what Nav_open_url reads behind +> > the "#") in DwGtkScroller (which I find somehow logical), but this is +> > only a detail which may be changed. +> +> Yes, to DwPage. +> In the next release I'll include more documentation about Dw. +> +> Doc Preview :-) +> +> DwGtkScroller is the topmost widget, it contains the vertical +> and horizontal scrollers and GtkDwView. GtkDwView serves as the +> container for the topmost Dw. +> When the HTML page changes, these widgets remain, only the +> topmost Dw is destroyed and new one created. +> +> So, it seems to me that te #anchor belongs to DwPage. + +The new DwPage does not exist in Nav_open_url, so I put the #anchor in +GtkDwScroller; but it is removed when it isn't used anymore. + +For an implementation of frames there should probably a new Dw widget +DwFrameSet or so, but since frames can be scrolled, the DwFrameSet may +perhaps itself contain other GtkDwScoller's with there own +#anchors, so (and because currently there aren't any concrete ideas +about frames) I don't change this (in the near future). + +> > However, "queuing" this adjustment +> > setting (in the case the page has to be loaded) brings some problems. +> > The way I mentioned (in Dw_page_rewrap or Html_open_a) does not work, +> > either a few others (e. g. Html_close). In any case, +> > gtk_adjustment_set_value is called, but is has no effect. +> +> What about adding an idle function to change the adjustment +> value when the #anchor is found? +> I mean, making a gtk idle function to poll the widget for the +> requested anchor until it succeeds, and after that, changing the +> adjustment value. + +Perhaps better a timeout function (with a small intervall of 200 ms or +so), since idle functions take a lot of CPU time. + +I have tested it and --- it did not work :-) + +But I have found a solution (based on a timeout function) that works! By +debugging I realized that there are problems when this timeout function +accesses the DwPage's hashtable (again threads?), so I rewrote this +function, so it does not access the hashtable in any case. In theory +this should work always, in practise there are a few problems in some +special cases, but I think this is the right way. + +> [...] +> Ah, let me know if you'd prefer to continue working the patch +> after next release (having the docs and new code), or to try to +> push it into dillo 0.2.3. + +Docs is currently not the matter (unless I would find out a much more +elegant solution after I've better understood the code ;-), but there is +still a bit to do, so it depends on when you are planning to release +version 0.2.3. + +Sebastian. + + + +RE: [Dillo-dev]Re: Eric + +From: Eric GAUDET - 2000-07-27 05:05 + +Le 26-Jul-2000, on m'a dit : +> Considering your skills, you have several choices to contribute! +> +> - We need to assemble an HTML test suite. I have a bunch of +> pages for that purpose, but it'd be great to make a master HTML +> testing page with short descriptive links of what the page is +> meant to test. We coul finally wrap it into a tar.gz and make +> it available to other developers. +> + +I can do that. I'll submit the first pages in a day or two (the documentation +will be in the page itself ;-). + +> - Finding bugs, identifying them and making good entries at the +> bug track. +> + +I'm already doing that. I'm not sure I'm doing "good entries" tough ;-) + +> - Making a screenshots page for dillo (A few jpg thumbs with +> links to middle sized jpg images). +> + +I can do that too. Middle sized would be 640x480 max ? Do you want me to do the +page to present them too ? + +> - Implementing the bookmarks as an external plugin. The idea of +> doing it keeps rolling in my mind. Basically a dpi:/ (dillo +> plugin) URL can be defined, and when accessing dpi:/bm (bookmark) +> an external program can be launched on a thread to 'cat' the +> bookmarks file (this is very much like current file handling). +> The point with this scheme is that the plugin can be extended +> to achieve more functionality (add, move, remove bookmark, make +> category, etc). All implemented in a CGI fashioned way. +> With that example, other people can start thinking of other +> plugins, like a man page processor, or info file processor, a +> dillorc options interface, etc. +> + +You said that before and I love this idea. I'd like to see a practical example +of plugin, even alpha stage, before I decide I can do it right. +What I understand, is there's a program called bm in ~/.dillo/plugin/ or +/usr/local/lib/dillo/ (or is it /usr/local/share/dillo/ ?), that take its +arguments on the command line (ie : when calling the URL +"dpi:/bm?subdirectoy=News&fontsize=16", dillo is opening a read only pipe with +the command line "bm subdirectory=News fontsize=16"), then the program "bm" +prints a html page in stdout (and can do something else, like writing a file +on the disk), which page dillo will render. +Is that what you have in mind ? If not, can you describe precisely the calling +mecanism, as well as the data retrieving. + +> - Finish the 64bit CPU support. +> I've been working on that. Standarized type handling and made +> dillo compilable with lcc. Dillo "runs" on 64bit machines, but +> very bad. +> + +I definitly can't do that, unless I benefit a donation of a 64bit workstation +;-) + +---------------------------------- +Eric GAUDET +Le 27-Jul-2000 a 12:17:08 +---------------------------------- + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Jorge Arellano Cid - 2000-07-27 00:23 + +Sebastian, +(and everyone interested in Dw internals) + +> I indeed store the offsets in a hashtable (stored in DwPage, see below), +> but these pseudo-widget are to make recalculating of them simpler when +> the page is resized. More precisely, I added mainly following until now: +> +> - Html_tag_open_a adds an anchor to the page and stores its current +> offset in this hashtable. (This is done by a new function +> a_Dw_page_add_anchor.) +> +> - In Dw_page_rewrap this value is corrected. This is needed for resizing +> of the page, as well as for images whose size changes (to the correct +> value, after the size has been determined). +> +> - I added a bit code to Nav_open_url, which I described already (see +> below, after "> > ") +> +> This first two points already work quite well. +> +> If the page with this anchor has already be loaded (completely), when +> Nav_open_url is called, only a gtk_adjustment_set_value(...) is needed. +> This works already. + +Nice! [suggestions below] + + +> > > o The point to start is Nav_open_url. This function should get the +> > > requested anchor after the "#" and store it somewhere. +> > +> > I think the best place for it is within the linkblock. This +> > structure is used to handle auxiliary data structures derived +> > from HTML procesing (as forms, base URL, etc). +> > +> +> How long does a linkblock exist? The reason, why I stored the hashtable +> for anchors in DwPage, is because these informations should exist as +> long the user views the page. That is exactly as long the DwPage exists. + +At least until the form is sent :-) +Use DwPage, I agree with you. + +> > > Probably, the +> > > page should not be loaded when the href points to an anchor in the same +> > > file. Later, the pixel position should be calculated. "Later" means: +> > > +> > > - when the page has already been loaded: immediatly, or +> > > - otherwise: when the lines in the page are wrapped, or, perhaps, +> > > already when the correct is read (probably not). +> > > +> > > The last problem does not seem too hard. +> But in practise, it *is* :-) + +See suggestions below. + +> > If we put the anchor (lets think of a gchar*) in the linkblock, +> > NULL can mean NO anchor (draw from top), and anything else, draw +> > from anchor. A new #anchor in the same page overwrites the former +> > one. +> > +> > That way, we won't fool the user when pressing the BACK key. +> > One click would show the #anchor-scrolled page from the top and +> > the next one would go back. +> +> Do you mean to ignore the text before the ? I thought of +> setting the value of the DwGtkScroller's GtkAdjustment, so that the user +> can scroll back and view the text before the anchor. + +I meant exactly what you wrote! +(My point was not to queue multiple #anchor references, of the +same page, in the navigation stack) + + +> > > My question is: where to store the requested anchor? +> > > [...] +> > +> > As I wrote above, my vote goes to the linkblock. + +Well, leave it in DwPage for now. Maybe in the future we'll use +DwPage as a base widget for frames, and it seems simpler. + + +> Currently, I store the requested anchor (what Nav_open_url reads behind +> the "#") in DwGtkScroller (which I find somehow logical), but this is +> only a detail which may be changed. + +Yes, to DwPage. +In the next release I'll include more documentation about Dw. + +Doc Preview :-) + +DwGtkScroller is the topmost widget, it contains the vertical +and horizontal scrollers and GtkDwView. GtkDwView serves as the +container for the topmost Dw. +When the HTML page changes, these widgets remain, only the +topmost Dw is destroyed and new one created. + +So, it seems to me that te #anchor belongs to DwPage. + + +> However, "queuing" this adjustment +> setting (in the case the page has to be loaded) brings some problems. +> The way I mentioned (in Dw_page_rewrap or Html_open_a) does not work, +> either a few others (e. g. Html_close). In any case, +> gtk_adjustment_set_value is called, but is has no effect. + +What about adding an idle function to change the adjustment +value when the #anchor is found? +I mean, making a gtk idle function to poll the widget for the +requested anchor until it succeeds, and after that, changing the +adjustment value. + +> A reason for this may be the different threads, and I think Gtk isn't +> thread-save (what is generally a problem with X). + +OH, I'll try to include more documentation (already wrote, but +in .ps format...) + +Doc preview 2: + +The threaded systems in dillo were isolated for use only by the +dns engine and file transfer. They don't mess with shared memory, +and data exchange is carried on with pipes. +Threads don't access, nor use GTK+ code. + +Plainly stated: If you're coding for dillo, and don't change +anything in dns.c and file.c, you can forget about threads! + + +> Actually, somehow the +> text "gets visible" (sorry for this vague expression, but I don't know, +> where), and this point is perhaps to continue. Perhaps someone can give +> me some hints. + +Sure, I've had problems too when trying to understand it. + +Weird behaviour is most notably due to an incomplete +implementation of the Dw mechanism. For instance: + +Dw_gtk_view_adjustment_changed does NOTHING! +(But it gets called) + +I used Dw_gtk_view_v_scroll to solve the scrolling problem. If +scrolling presents weird behaviour for you, start investigating +from there. + +Ah, let me know if you'd prefer to continue working the patch +after next release (having the docs and new code), or to try to +push it into dillo 0.2.3. + +-- +-- + +Ah, I've been working out the code, improved the rendering speed +(yes it was possible), removed several segfault sources, fixed +some bugs, etc. +It seems we're close to 0.2.3. + + +Regards +Jorge.- + + + +[Dillo-dev]Re: Eric + +From: Jorge Arellano Cid - 2000-07-27 00:23 + +Hi everyone! +(This is mainly several replies to Eric's posts, +but it's intended to everyone) + +> ... +> However, is it a good thing, +> when location bar focused, to map left and right arrows to move +> the cursor, and up, down, page up, page down to scroll the page? + +I'm not sure, but it has proven practical! +Let's keep it that way until someone comes with something better. + +> [personal skills] +> I'd love to contribute to dillo, but I'd prefer the code to +> be more documented. + +Me too! +Documentation has been one of the key points in our efforts. We +have advanced a lot with it (documenting inside and outside the +code), but there's still work to do. No doubt. + +I'll include more docs in the next release (I write them as fast +as I can). I'd also appreciate some feedback on the subject. What +is already clear from the docs, and what needs more work. No one +has written me a single line about it :-( --AFAIR + +-- + +Considering your skills, you have several choices to contribute! + +- We need to assemble an HTML test suite. I have a bunch of +pages for that purpose, but it'd be great to make a master HTML +testing page with short descriptive links of what the page is +meant to test. We coul finally wrap it into a tar.gz and make +it available to other developers. + +- Finding bugs, identifying them and making good entries at the +bug track. + +- Making a screenshots page for dillo (A few jpg thumbs with +links to middle sized jpg images). + +- Implementing the bookmarks as an external plugin. The idea of +doing it keeps rolling in my mind. Basically a dpi:/ (dillo +plugin) URL can be defined, and when accessing dpi:/bm (bookmark) +an external program can be launched on a thread to 'cat' the +bookmarks file (this is very much like current file handling). +The point with this scheme is that the plugin can be extended +to achieve more functionality (add, move, remove bookmark, make +category, etc). All implemented in a CGI fashioned way. +With that example, other people can start thinking of other +plugins, like a man page processor, or info file processor, a +dillorc options interface, etc. + +- Finish the 64bit CPU support. +I've been working on that. Standarized type handling and made +dillo compilable with lcc. Dillo "runs" on 64bit machines, but +very bad. + + +Just tell me what you'd like to do (volunteers welcome). + +Sincerely +Jorge.- + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Sebastian Geerken - 2000-07-25 15:33 + +Hi, again! + +Jorge Arellano Cid wrote: +> +> Sebastian, +> +> On 11 Jul 2000, Sebastian Geerken wrote: +[...] +> > 2. My basic idea is: +> > +> > o Extend the DwPage widget: add a new DW_PAGE_CONTENT_ANCHOR, which has +> > zero size and is not drawn in any way. +> +> Are you planning to get the offset from this pseudo-widget? +> + +I indeed store the offsets in a hashtable (stored in DwPage, see below), +but these pseudo-widget are to make recalculating of them simpler when +the page is resized. More precisely, I added mainly following until now: + +- Html_tag_open_a adds an anchor to the page and stores its current +offset in this hashtable. (This is done by a new function +a_Dw_page_add_anchor.) + +- In Dw_page_rewrap this value is corrected. This is needed for resizing +of the page, as well as for images whose size changes (to the correct +value, after the size has been determined). + +- I added a bit code to Nav_open_url, which I described already (see +below, after "> > ") + +This first two points already work quite well. + +If the page with this anchor has already be loaded (completely), when +Nav_open_url is called, only a gtk_adjustment_set_value(...) is needed. +This works already. + +> > o The point to start is Nav_open_url. This function should get the +> > requested anchor after the "#" and store it somewhere. +> +> I think the best place for it is within the linkblock. This +> structure is used to handle auxiliary data structures derived +> from HTML procesing (as forms, base URL, etc). +> + +How long does a linkblock exist? The reason, why I stored the hashtable +for anchors in DwPage, is because these informations should exist as +long the user views the page. That is exactly as long the DwPage exists. + +> > Probably, the +> > page should not be loaded when the href points to an anchor in the same +> > file. Later, the pixel position should be calculated. "Later" means: +> > +> > - when the page has already been loaded: immediatly, or +> > - otherwise: when the lines in the page are wrapped, or, perhaps, +> > already when the correct is read (probably not). +> > +> > The last problem does not seem too hard. +But in practise, it *is* :-) + +> +> If we put the anchor (lets think of a gchar*) in the linkblock, +> NULL can mean NO anchor (draw from top), and anything else, draw +> from anchor. A new #anchor in the same page overwrites the former +> one. +> +> That way, we won't fool the user when pressing the BACK key. +> One click would show the #anchor-scrolled page from the top and +> the next one would go back. + +Do you mean to ignore the text before the ? I thought of +setting the value of the DwGtkScroller's GtkAdjustment, so that the user +can scroll back and view the text before the anchor. + +> +> > My question is: where to store +> > the requested anchor? BrowserWindow would be simple, but when frames are +> > implemented later, the requested anchor should belong to a frame. DwPage +> > would be better, but when I follow all the created structures, there is +> > a break in the IO/Mime module where the anchor gets lost (?). What about +> > DwBorder becoming a base Widget for a frame? +> +> As I wrote above, my vote goes to the linkblock. +> We're still one step behind the frame implementation design. +> Currently we're aiming towards a table representation for it. +> Anyway, if it would finally get implemented in adifferent way, +> the information, most probably would end in the linkblock! +> + +Currently, I store the requested anchor (what Nav_open_url reads behind +the "#") in DwGtkScroller (which I find somehow logical), but this is +only a detail which may be changed. However, "queuing" this adjustment +setting (in the case the page has to be loaded) brings some problems. +The way I mentioned (in Dw_page_rewrap or Html_open_a) does not work, +either a few others (e. g. Html_close). In any case, +gtk_adjustment_set_value is called, but is has no effect. + +A reason for this may be the different threads, and I think Gtk isn't +thread-save (what is generally a problem with X). Actually, somehow the +text "gets visible" (sorry for this vague expression, but I don't know, +where), and this point is perhaps to continue. Perhaps someone can give +me some hints. + +Sebastian. + + + +Re: [Dillo-dev]Bug #57 + +From: Sebastian Geerken - 2000-07-25 08:19 + +Jorge Arellano Cid wrote: +> +> Hi! +> +> Can anyone tell me how to reproduce bug #57? The procedure in +> the bug-track works fine for me (no bug). +> +> Jorge.- +> + +I once encountered this bug (not by intention!), but I think it was in +dillo 0.2.0. As I remember, it was due to some strange characters in the +title; perhaps this hint might help. + +Otherwise: If I start dillo and open a new window (File/New Browser), +the new window always has an empty bookmark menu. This is so strange +that it seems to be intended ;-) + + + +RE: [Dillo-dev]Bug #57 + +From: Eric GAUDET - 2000-07-25 01:50 + +Le 24-Jul-2000, on m'a dit : +> +> Hi! +> +> Can anyone tell me how to reproduce bug #57? The procedure in +> the bug-track works fine for me (no bug). +> +> Jorge.- +> + +I don't konw if it's related, but the page shown by "view bookmarks" (file +~/.dillo/bookmarks.html) doesn't list the same bookmarks than those in the +"bookmark" menu : the bookmark menu contains all bookmarked URLs, but the +bookmark file is only updated when exiting dillo, thus containing only the URLs +present at dillo's launch. +No random char for me. (dillo v0.2.2 with focus patch) + +---------------------------------- +Eric GAUDET +Le 24-Jul-2000 a 23:07:33 +---------------------------------- + + + +[Dillo-dev]Bug #57 + +From: Jorge Arellano Cid - 2000-07-24 12:56 + +Hi! + +Can anyone tell me how to reproduce bug #57? The procedure in +the bug-track works fine for me (no bug). + +Jorge.- + + + +Re: [Dillo-dev]Bug #54 : a hint + +From: Eric GAUDET - 2000-07-19 09:19 + +Le 19-Jul-2000, on m'a dit : +> Eric, +... +> I sent you a patch for testing (private email), but if your +> will to help is so good as described above, I'd very much like to +> know your skills, just to know what I can ask you to do. +> +> Sincerely +> Jorge.- +> + +Patch tested and answered. I've never done gtk developement (nor motif, qt or +any X toolkit), but I've been coding on linux for a year or so (C, pthreads, +java, php3, html, sql), and I know how to compile and trace a program with +xxgdb (I still have trouble with makefiles, no improvement to expect here +because I'm heavily using CodeCrusader with automated makefiles generation, and +I've got to read the man pages everytime I want to apply patches ;-) +I haven't done C++ for a while, since I'm no more doing Visual C++ +developement. I wasn't so good doing that anyway :-/ +The "bigest" linux coding project I've been involved in is recoding a dockapp +(wmtime) for my own fits. Dockapps only use Xlib for rendering. ... oh, and I +tried to improve gnome-o-phone sending patches, but I stoped it because of an +argument with the maintener because applying my patches was too much work for +him. + +I'd love to contribute to dillo, but I'd prefer the code to be more documented. + +PS: I also know quite well forth, asm68k, and Dr's GEM toolkit, but I don't +think you'll find that usefull for dillo ;-) + +---------------------------------- +Eric GAUDET +Le 19-Jul-2000 a 18:03:25 +"Not so long ago if you had a 3 1/2 inch floppy +you hoped nobody found out!" +---------------------------------- + + + +Re: [Dillo-dev]Bug #54 : a hint + +From: Jorge Arellano Cid - 2000-07-19 01:17 + +Eric, + +> [BUG 54] +> If you guys need me to track this bug down, you just have to ask : I can +> reproduce it every time. I can change to gtk-1.2.6, or whatever you ask. I +> don't know what informations are pertinent for this problem (parameters passed +> to the gtk_signal_emit_by_name() that can cause errors), name them and I'll do +> a complete report. + +I sent you a patch for testing (private email), but if your +will to help is so good as described above, I'd very much like to +know your skills, just to know what I can ask you to do. + +Sincerely +Jorge.- + + + +[Dillo-dev]Dw? + +From: Jorge Arellano Cid - 2000-07-18 00:35 + +Hi there! + +Here's a question that keeps comming back to me: + +Q: What's the point in having the whole Dillo Widget mechanism +over having a simple GTK+-derived widget set? + +I've found reasons like eliminating the window creation +overhead for images, but, is that the main point of it? I doubt. + + +Any light on the subject is welcomed. +Jorge.- + + + +[Dillo-dev]Bug #58 same as #58 ? + +From: Eric GAUDET - 2000-07-15 14:50 + +Hi guys, +I've read the bug list, and I have the feeling bug #35 and bug #58 are the same +(#35 looks like an extreme case of #58 where the "small" page is scrolled too +high) +Does this info help ? + +---------------------------------- +Eric GAUDET +Le 15-Jul-2000 a 23:46:53 +---------------------------------- + + + +Re: [Dillo-dev]Bug #54 : a hint + +From: Eric GAUDET - 2000-07-15 14:47 + +Le 14-Jul-2000, on m'a dit : +> Il ven, 14 lug 2000, hai scritto: +> > Hi again, +> +> > There's still some weird code around "the line". +> > Would you mind sending me a short patch Luca? +> +> As you noticed Dw is incomplete. And it has some problem with focus, too. +> +> Without Interface_handle_key_event() when the location bar has the focus and +> you press Arrow Down (or Tab) the focus is lost. But Dw (and then Dw_view) +> doesn't get it. +> + +... + +> +> If gtk_signal_emit_by_name() gives some problem well it's safe deleting this +> line. But it's not a definitive solution. Please note that I've no problem +> with gtk-1.2.6. +> + +If you guys need me to track this bug down, you just have to ask : I can +reproduce it every time. I can change to gtk-1.2.6, or whatever you ask. I +don't know what informations are pertinent for this problem (parameters passed +to the gtk_signal_emit_by_name() that can cause errors), name them and I'll do +a complete report. + +---------------------------------- +Eric GAUDET +Le 15-Jul-2000 a 23:42:08 +---------------------------------- + + + +Re: [Dillo-dev]Bug #54 : a hint + +From: Luca Rota - 2000-07-15 12:54 + +Il ven, 14 lug 2000, hai scritto: +> Hi again, + +> There's still some weird code around "the line". +> Would you mind sending me a short patch Luca? + +As you noticed Dw is incomplete. And it has some problem with focus, too. + +Without Interface_handle_key_event() when the location bar has the focus and +you press Arrow Down (or Tab) the focus is lost. But Dw (and then Dw_view) +doesn't get it. + +With Interface_handle_key_event() when the location bar has the focus and you +press Arrow Down (or Arrow Up, Page Down, Page Up) this handler send a signal +(with gtk_signal_emit_by_name()) to dw_view and stop the original signal. If we +delete gtk_signal_emit_by_name(), dw_view doesn't get the key_press event and so +the page isn't scrolled. If we delete gtk_signal_emit_stop_by_name() the +location bar will lose the focus. + +If gtk_signal_emit_by_name() gives some problem well it's safe deleting this +line. But it's not a definitive solution. Please note that I've no problem with +gtk-1.2.6. + +Ciao, +Luca + + + +Re: [Dillo-dev]Bug #54 : a hint + +From: Jorge Arellano Cid - 2000-07-13 23:39 + +Hi again, + +On Mon, 10 Jul 2000, Luca Rota wrote: + +> > Commenting this line prevents dillo form segfaulting when pressing PgUp, +> > PgDown, Up and Down arrows, but I'm pretty sure this line has a purpose ;-) and +> > just removing it is not what you'd call "clean fix". +> +> Now, I think, it's safe deleting this line. +> With my RedHat Linux box and gtk 1.2.6 I've no problem. + +There's still some weird code around "the line". +Would you mind sending me a short patch Luca? + +Jorge.- + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Jorge Arellano Cid - 2000-07-13 23:39 + +Sebastian, + + +On 11 Jul 2000, Sebastian Geerken wrote: + +> Hi! +> +> I'm currently working on anchors (to get URL's like "foo#bar" rendered +> correctly, bug #10), and I have two questions: + +Good! +That's would make dillo much better. + +> 1. Does anyone do anything on tables? It's because I will change the +> DwPage widget, and this is probably also necessary for tables; so we +> should avoid to get problems patching both togeher. + +Yes, and No :-) +Currently we're studying Dw in order to understand it +thoroughly and document it (I have three pages written now). +Although I have made several patches inside it, the general +design behind it is still somewhat obscure to me; with my latest +studies I've began to understand why: Dw is incomplete! + +Yes, it was designed (by Raph Levien) to manage an interesting +bunch of funcionality, but some of its key parts are not +implemented yet! + +For instance, embedded GTK+ widgets can't pass resize requests +to their respective Dw containers (this is necessary if tables +are to be implemented with GTK+ widgets). +Some parts of the rewrap and paint stuff are still waiting to +be completed. + +So, our current work consists on studying Dw, documenting it, +with a view to decide what to extend (or change) and finally +start designning our table handling scheme upon that base. + +(I've also sent emails to Raph, but have had no answers. Maybe +he's on vacation; it's summer there in Europe!) + +> 2. My basic idea is: +> +> o Extend the DwPage widget: add a new DW_PAGE_CONTENT_ANCHOR, which has +> zero size and is not drawn in any way. + +Are you planning to get the offset from this pseudo-widget? + +> o The point to start is Nav_open_url. This function should get the +> requested anchor after the "#" and store it somewhere. + +I think the best place for it is within the linkblock. This +structure is used to handle auxiliary data structures derived +from HTML procesing (as forms, base URL, etc). + + +> Probably, the +> page should not be loaded when the href points to an anchor in the same +> file. Later, the pixel position should be calculated. "Later" means: +> +> - when the page has already been loaded: immediatly, or +> - otherwise: when the lines in the page are wrapped, or, perhaps, +> already when the correct is read (probably not). +> +> The last problem does not seem too hard. + +If we put the anchor (lets think of a gchar*) in the linkblock, +NULL can mean NO anchor (draw from top), and anything else, draw +from anchor. A new #anchor in the same page overwrites the former +one. + +That way, we won't fool the user when pressing the BACK key. +One click would show the #anchor-scrolled page from the top and +the next one would go back. + +> My question is: where to store +> the requested anchor? BrowserWindow would be simple, but when frames are +> implemented later, the requested anchor should belong to a frame. DwPage +> would be better, but when I follow all the created structures, there is +> a break in the IO/Mime module where the anchor gets lost (?). What about +> DwBorder becoming a base Widget for a frame? + +As I wrote above, my vote goes to the linkblock. +We're still one step behind the frame implementation design. +Currently we're aiming towards a table representation for it. +Anyway, if it would finally get implemented in adifferent way, +the information, most probably would end in the linkblock! + + +Jorge.- + + + +[Dillo-dev]Bug #10 (Anchors): questions + +From: Sebastian Geerken - 2000-07-11 15:32 + +Hi! + +I'm currently working on anchors (to get URL's like "foo#bar" rendered +correctly, bug #10), and I have two questions: + +1. Does anyone do anything on tables? It's because I will change the +DwPage widget, and this is probably also necessary for tables; so we +should avoid to get problems patching both togeher. + +2. My basic idea is: + +o Extend the DwPage widget: add a new DW_PAGE_CONTENT_ANCHOR, which has +zero size and is not drawn in any way. + +o The point to start is Nav_open_url. This function should get the +requested anchor after the "#" and store it somewhere. Probably, the +page should not be loaded when the href points to an anchor in the same +file. Later, the pixel position should be calculated. "Later" means: + +- when the page has already been loaded: immediatly, or +- otherwise: when the lines in the page are wrapped, or, perhaps, +already when the correct is read (probably not). + +The last problem does not seem too hard. My question is: where to store +the requested anchor? BrowserWindow would be simple, but when frames are +implemented later, the requested anchor should belong to a frame. DwPage +would be better, but when I follow all the created structures, there is +a break in the IO/Mime module where the anchor gets lost (?). What about +DwBorder becoming a base Widget for a frame? + +Any suggestions? + +Sebastian. + + + +Re: [Dillo-dev]dillo-0.2.2 + +From: - 2000-07-11 01:49 + +On Sun, 9 Jul 2000, Jorge Arellano Cid wrote: + +> Some time ago I was informed that dillo compiled with freeBSD +> (with lots of segfaults at run time); was that a 64bit machine? +> which compiler? (He's a member of this list!). + +That was me. I'm using a 32bit machine, gcc 2.7.2.3, and frebsd 3.5. I +suppose that my freebsd compilation doesn't really crash much more than +my linux one (or netscape for that matter...). BTW, the only tweak I +needed for 0.2.2. was to use -pthread instead of -lpthread. + + + +Re: [Dillo-dev]Bug #54 : a hint + +From: Luca Rota - 2000-07-10 16:02 + +Il lun, 10 lug 2000, hai scritto: + +> This bug has something to do with interface.c line1048 : +> in Interface_handle_key_event() +> +> gtk_signal_emit_by_name (GTK_OBJECT (dw_view), "key_press_event", event); +> +Uh! Let me see! +Oh! yes, I remember! + +Some release ago dillo had a bug which prevents form to be focused. And so, +with gtk 1.2.4 and before the patch for that bug gtk_signal was a little hack. + +> Commenting this line prevents dillo form segfaulting when pressing PgUp, +> PgDown, Up and Down arrows, but I'm pretty sure this line has a purpose ;-) and +> just removing it is not what you'd call "clean fix". + +Now, I think, it's safe deleting this line. +With my RedHat Linux box and gtk 1.2.6 I've no problem. + +Ciao, +Luca + + + +[Dillo-dev]Bug #54 : a hint + +From: Eric GAUDET - 2000-07-10 07:03 + +This bug has something to do with interface.c line1048 : +in Interface_handle_key_event() + +gtk_signal_emit_by_name (GTK_OBJECT (dw_view), "key_press_event", event); + +Commenting this line prevents dillo form segfaulting when pressing PgUp, +PgDown, Up and Down arrows, but I'm pretty sure this line has a purpose ;-) and +just removing it is not what you'd call "clean fix". + +I'm not much familiar with gtk coding. Can anyone tell me what this line does ? +(I mean : I know it emits a signal named "key_press_event" ; what I want +to know is how dillo is dealing with this signal. It seems that its only +purpose is to call Interface_handle_key_event, the very same function the +emission is from ???) + +Le 09-Jul-2000, on m'a dit : +> Ah, there's a bug (#54) in the bug track engine that seems to +> concern GTK+, not dillo. Anyway, I'm using GTK+-1.2.6 and don't +> have any trouble with it (no segfault with the described +> procedure). Which GTK+ version (or OS) is the poster using? +> --just curiousity. +> + +---------------------------------- +Eric GAUDET +Le 10-Jul-2000 a 15:26:13 +"Not so long ago if you had a 3 1/2 inch floppy +you hoped nobody found out!" +---------------------------------- + + + +RE: [Dillo-dev]dillo-0.2.2 + +From: Eric GAUDET - 2000-07-10 03:10 + +Le 09-Jul-2000, on m'a dit : +> Ah, there's a bug (#54) in the bug track engine that seems to +> concern GTK+, not dillo. Anyway, I'm using GTK+-1.2.6 and don't +> have any trouble with it (no segfault with the described +> procedure). Which GTK+ version (or OS) is the poster using? +> --just curiousity. +> + +Thats me. This bug is very reproductible : every time (for me). +I'm on linux kernel 2.4.0-test2-ac2, based on Mandrake 7.0, with +gtk+-1.2.7 and glib-1.2.7. + +I'll try to track this bug, though it seems burried in a 15 or so deep gtk-call +:-/ + +Where is the code for the URL box ? (init and loop) + +(PS: I got some segfault I can't reproduce, after browsing a few pages (on +0.2.1)) + +---------------------------------- +Eric GAUDET +Le 10-Jul-2000 a 11:54:28 +"Not so long ago if you had a 3 1/2 inch floppy +you hoped nobody found out!" +---------------------------------- + + + +[Dillo-dev]Dillo web-page comments (fwd) + +From: Jorge Arellano Cid - 2000-07-10 00:53 + +Hi there! + +I just received this email and frankly, I think skeff is right: + +---------- Forwarded message ---------- +Date: Sun, 09 Jul 2000 23:11:58 +0300 +From: skeff +To: jcid@ma... +Subject: Dillo web-page comments + +Ok site and all that. +But hey, SCREENSHOTS !!! ;) + +People don't bother downloading your program unless you have a +screenshots, or if they're very interested. + +-skeff +--------------------------------------- + +If there's someone willing to make that, it'd be great. +An HTML page with, let's say five small thumbnails and their +links (jpeg images). +OK, if you just send me the thumbs and full-pictures pairs +that'll be enough to build the page. +If you plan to commit yourself with the task, please send an +email to this list to let others know it has been taken. + +Thanks a lot. +Jorge.- + + + +[Dillo-dev]dillo-0.2.2 + +From: Jorge Arellano Cid - 2000-07-09 18:59 + +Hi! + +Well, maybe a little delayed, but dillo-0.2.2 is finally +there, ready for download. I think the wait was worth the delay +because it finally can handle forms very much better, and there's +also an option that will let slashdot fans read the site. There +are several other improvements and changes detailed in the +Changelog. + +I want to thank every single patch you've sent me and hope you +enjoy this release. + +Ah, there's a bug (#54) in the bug track engine that seems to +concern GTK+, not dillo. Anyway, I'm using GTK+-1.2.6 and don't +have any trouble with it (no segfault with the described +procedure). Which GTK+ version (or OS) is the poster using? +--just curiousity. + +For those of you that had worked in the HTML parser, this +release comes with some significant changes. Basically the +parsing stack was modified with a clearer design (you'll easily +get it from the code). Form processing no longer depends on the +stack, but only on the linkblock. The child_linkblock was also +integrated into the html_linkblock. + +Several changes had taken place in order to achieve +compatibility with lcc compiler (it enhances portability). +Although I got dillo to compile with lcc, I can't still make it +run well on 64 bit machines. + +Some time ago I was informed that dillo compiled with freeBSD +(with lots of segfaults at run time); was that a 64bit machine? +which compiler? (He's a member of this list!). + + +Jorge.- + + diff --git a/old/oldmail/200008.txt b/old/oldmail/200008.txt new file mode 100644 index 0000000..8133b5d --- /dev/null +++ b/old/oldmail/200008.txt @@ -0,0 +1,3527 @@ +Re: [Dillo-dev]bug#77 is anchor-related + +From: Sebastian Geerken - 2000-08-27 16:32 + +Eric GAUDET wrote: +> +> Hi all, +> bug#77 (segfault with http://www.w3.org/TR/html4/) has to do with +> Dw_page_set_scroller_pos. For an unknown (to me, at least ;-) reason, +> dw->container is null for one widget, doing a segfault when accessed. +> This is related to anchors, so I hope Sebastian can fix that easilly ;-) + +Funny, I've inserted this bug. ;-) + +Dw_page_set_scroller_pos searches the GtkDwScroller that "contains" +the DwPage. Normally, page->parent is a DwBorder, page->parent->parent +is NULL (i. e. the DwBorder is a toplevel Dw widget), and +page->parent->container->widget point to the GtkDwView (a normal Gtk+ +widget, which parent is the GtkDwScroller). page->container is always +NULL. + +When examining the bug, I found that page->parent is NULL (and also +page->container). The bug seems to lie deeper in Dw, but since Dw is +planned to be elemenated and relaced by Gtk+, I'd suggest to forget +it. ;-) + +Sebastian + + + +[Dillo-dev]bug#77 is anchor-related + +From: Eric GAUDET - 2000-08-27 14:07 + +Hi all, +bug#77 (segfault with http://www.w3.org/TR/html4/) has to do with +Dw_page_set_scroller_pos. For an unknown (to me, at least ;-) reason, +dw->container is null for one widget, doing a segfault when accessed. +This is related to anchors, so I hope Sebastian can fix that easilly ;-) + +---------------------------------- +Eric GAUDET +Le 27-Aug-2000 a 23:01:22 +---------------------------------- + + + +Re: [Dillo-dev]support for background images? + +From: Sebastian Geerken - 2000-08-26 14:30 + +Sean 'Shaleh' Perry wrote: +> That said, please do visit the html validator link I sent previously. In css +> supporting browsers, a line of incorrect html is set against a grey background. + +At least it is readable in dillo. ;-) + +> We have to be able to affect the appearance of a page on a per word basis. + +Currently, DwPage can assign attributes to words. I don't think it is +too difficult to add backgrounds to DwPageAttr. I'll test it soon. + +Sebastian + + + +[Dillo-dev]bug no insertion : I'm patching lists + +From: Eric GAUDET - 2000-08-26 13:18 + +Hi all, +the inserting in bug tracking engine doesn't work for me (server +internal error). +Be aware I'm partching the lists tags and dw_bullets right now, to make +attribute type being recognized (both OL and UL), and also to correct +the bug about numbering reported a few days ago. + +I wont address bug#78 this time because it's a P tag problem. + +---------------------------------- +Eric GAUDET +Le 26-Aug-2000 a 16:29:43 +---------------------------------- + + + +Re: [Dillo-dev]support for background images? + +From: Sean 'Shaleh' Perry - 2000-08-26 10:00 + +> I'm currently working on DwPage (table sections will be DwPage's, +> too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in +> Html_tag_open_body), I'll set it as the the page's background. (I +> hope. ;-) +> + +hmm, seems the dicache and the rest of the image code assumes the goal is to +place the image on the page. Will have to read thru the entire image code to +lay this out and understand a proper implementation. Sounds like this can wait +(-: + + + +Re: [Dillo-dev]support for background images? + +From: Sean 'Shaleh' Perry - 2000-08-26 09:37 + +> I'm currently working on DwPage (table sections will be DwPage's, +> too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in +> Html_tag_open_body), I'll set it as the the page's background. (I +> hope. ;-) +> + +will add this to my list of things todo. + +That said, please do visit the html validator link I sent previously. In css +supporting browsers, a line of incorrect html is set against a grey background. +We have to be able to affect the appearance of a page on a per word basis. + + + +Re: [Dillo-dev]support for background images? + +From: Sebastian Geerken - 2000-08-26 09:25 + +Sean 'Shaleh' Perry wrote: +> +> Thought I would toss this out in the mess of ideas lately: +> +> we ought to support background images. style sheets allow you to specify +> backgrounds for just about everything. So, what would be best is a mechanism +> for: +> +> load image +> place image in the background of widget X +> +> X could be Page, table section, etc. +> +> Seems funny that the bug list looks better in ns than in dillo (-: + +I'm currently working on DwPage (table sections will be DwPage's, +too). If anyone succeeds in getting an GdkPixmap from a href (e.g. in +Html_tag_open_body), I'll set it as the the page's background. (I +hope. ;-) + +Sebastian + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Eric GAUDET - 2000-08-26 03:21 + +Le 25-Aug-2000, on m'a dit : +> > ok, what about both, then (anchors and headings) ? Some of them can +> > be +> > duplicates (anchor are often used to link to pararaphs titles). +> > And "Top of page" and "Bottom of page", even if not anchored, would +> > be +> > useful too. +> +> It's quite simple, I've begun to implement it (both headings and +> anchors). But I will not work on it the next time. Is anyone +> interested in completing it? I'll send him the patch. +> +> Sebastian + +I can try. Send me the patch. + +---------------------------------- +Eric GAUDET +Le 26-Aug-2000 a 12:21:03 +---------------------------------- + + + +[Dillo-dev]support for background images? + +From: Sean 'Shaleh' Perry - 2000-08-26 00:14 + +Thought I would toss this out in the mess of ideas lately: + +we ought to support background images. style sheets allow you to specify +backgrounds for just about everything. So, what would be best is a mechanism +for: + +load image +place image in the background of widget X + +X could be Page, table section, etc. + +Seems funny that the bug list looks better in ns than in dillo (-: + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Sebastian Geerken - 2000-08-25 18:59 + +Eric GAUDET wrote: +> +> Le 25-Aug-2000, on m'a dit : +> > Eric GAUDET wrote: +> > > Hi, +> > > I just thought about one (new idea?) feature about anchors : would +> > > it +> > > be possible to list them in a menu entry (Named "Chapters"? +> > > "Index"? +> > > "Content"?). Doing that, each time a page is loaded, this menu +> > > entry +> > > would be updated and the user could conveniently "jump" to anchors +> > > in +> > > the page without scrolling. +> > > +> > > What do you think ? +> > +> > That would be possible. But I think a menu of the anchors in a page +> > is not very useful. Better would be to list all the

...

. +> > That could also be possible by adding "pseudo anchors". If you get +> > a tag which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR +> > "@id" or so, where id is a unique number (unique in the page). +> > +> +> ok, what about both, then (anchors and headings) ? Some of them can be +> duplicates (anchor are often used to link to pararaphs titles). +> And "Top of page" and "Bottom of page", even if not anchored, would be +> useful too. + +It's quite simple, I've begun to implement it (both headings and +anchors). But I will not work on it the next time. Is anyone +interested in completing it? I'll send him the patch. + +Sebastian + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Eric GAUDET - 2000-08-25 14:22 + +Le 25-Aug-2000, on m'a dit : +> I didn't actually mean dillo's plugins (I currenty don't know how +> they work anyway), but some other sort of +> extend-dillo-without-modifying-the-sources, which could be called +> modules to avoid confusing. What I thought is: You can think of +> thousands of useful functions for dillo. When putting them all into +> dillo, the code gets big although a user might not use all these +> features. Indeed, such an interface should 1. be designed properly, +> and 2. not in the near future (currently we have other problems). +> + +Totally agreed ! (on everything : "thousands useful functions", "module +interface design", "we have other problems") What I was pointing out is +such a module interface design could be really tricky to come out with, +especially since it hasn't been planned of from the begining. + +> Sebastian +> +> PS1: I'm currently not interested in working on something like that, +> it was just an idea. ;-) +> + +While you're talking about that, I wanted to tell how nice it is to be +in that mailing list, with people throwing interesting ideas (even if +not interested in working on them ;-), nice and respectful ambiance (no +troll here : great !). + +> PS2: Counting characters is exotic enough that is reasonable to let +> the user save the page and start an other program. Trying to connect +> a webbrowser to all of the world is indeed quite idiotic. + +ok, that was a poor example, but who knows ? ;-) + +---------------------------------- +Eric GAUDET +Le 25-Aug-2000 a 23:09:58 +---------------------------------- + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Sebastian Geerken - 2000-08-25 13:43 + +Eric GAUDET wrote: +> [...] +> > Another idea: What about a mechanism to let the user ("user" is +> > anyone who does not changes the sources of dillo ;-) write such +> > things. +> > Perhaps plugins? The plugin transmits to dillo what is interesting +> > for it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id +> > for referring to the tags to the plugin. When a user clickes on an +> > item in the plugin's list, the plugin sends a url to dillo. +> > +> +> That would mean calling _every_ (registered) plugin each time a page +> is loaded. Seems possible, but that can slow down thing. +> Registering the tags is interesting because dillo doesn't have to send +> the whole page, and the plugin doesn't have to parse html. But I'm not +> sure that's how plugins are supposed to work, though I'm still waiting +> for complete plugins specs (Jorge ?). +> I mean : we'll have to change dillo's html parsing for that type of +> plugins ; what about a plugin wanting to count how many "e" there's in +> a page ? interesting, but we'll have to change dillo's sources for that. +> What about a pluggin wanting to scan images before rendered and censor +> those where there's too much "skin tones" ? interesting, but we'll have +> to change dillo's sources once again for that. +> The cleanest way would be to send each page to the pluggin, and wait for +> the plugin to render the page. The html parser could be a plugin : that +> way we could have a pdf-plugin, a rtf-plugin ... that would be nice. +> But that's not what we are doing : we are doing an html browser, and +> html source is intended to be in the browser, not sent to plugins. +> The way Jorge defined plugins (that can change) is clean and simple : a +> plugin call looks like a link ("dpi://myplugin"), some datas are sent +> (name=value type), the plugin sends back an html page (and possibly ask +> dillo to update its menus, but there's no protocol for that yet, though +> I'm working on it). That's it. There's no two-way interaction between +> dillo and the plugins. There is no possibility for a plugin to ask dillo +> about its internals, such as page source, history. +> Albeit your module/plugin idea is interesting, that would mean a big +> rewrite in dillo's whole html parsing and plugin system (I know, +> it's not written yet) just to avoid small changes in dillo's menus and +> anchor (and H1..h6) parsing. +> In a nutshell, I think it's better and easier to keep these things in +> dillo, until we define (not soon) a clear mecanisme for external +> modules, which aren't plugins. +> +> (man, _that's_ a long answer to a not very useful question ;-) + +I didn't actually mean dillo's plugins (I currenty don't know how they +work anyway), but some other sort of +extend-dillo-without-modifying-the-sources, which could be called +modules to avoid confusing. What I thought is: You can think of +thousands of useful functions for dillo. When putting them all into +dillo, the code gets big although a user might not use all these +features. Indeed, such an interface should 1. be designed properly, +and 2. not in the near future (currently we have other problems). + +Sebastian + +PS1: I'm currently not interested in working on something like that, +it was just an idea. ;-) + +PS2: Counting characters is exotic enough that is reasonable to let +the user save the page and start an other program. Trying to connect a +webbrowser to all of the world is indeed quite idiotic. + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Eric GAUDET - 2000-08-25 11:03 + +Le 25-Aug-2000, on m'a dit : +> Eric GAUDET wrote: +> > Hi, +> > I just thought about one (new idea?) feature about anchors : would +> > it +> > be possible to list them in a menu entry (Named "Chapters"? +> > "Index"? +> > "Content"?). Doing that, each time a page is loaded, this menu +> > entry +> > would be updated and the user could conveniently "jump" to anchors +> > in +> > the page without scrolling. +> > +> > What do you think ? +> +> That would be possible. But I think a menu of the anchors in a page +> is not very useful. Better would be to list all the

...

. +> That could also be possible by adding "pseudo anchors". If you get +> a tag which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR +> "@id" or so, where id is a unique number (unique in the page). +> + +ok, what about both, then (anchors and headings) ? Some of them can be +duplicates (anchor are often used to link to pararaphs titles). +And "Top of page" and "Bottom of page", even if not anchored, would be +useful too. + +> Another idea: What about a mechanism to let the user ("user" is +> anyone who does not changes the sources of dillo ;-) write such +> things. +> Perhaps plugins? The plugin transmits to dillo what is interesting +> for it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id +> for referring to the tags to the plugin. When a user clickes on an +> item in the plugin's list, the plugin sends a url to dillo. +> + +That would mean calling _every_ (registered) plugin each time a page +is loaded. Seems possible, but that can slow down thing. +Registering the tags is interesting because dillo doesn't have to send +the whole page, and the plugin doesn't have to parse html. But I'm not +sure that's how plugins are supposed to work, though I'm still waiting +for complete plugins specs (Jorge ?). +I mean : we'll have to change dillo's html parsing for that type of +plugins ; what about a plugin wanting to count how many "e" there's in +a page ? interesting, but we'll have to change dillo's sources for that. +What about a pluggin wanting to scan images before rendered and censor +those where there's too much "skin tones" ? interesting, but we'll have +to change dillo's sources once again for that. +The cleanest way would be to send each page to the pluggin, and wait for +the plugin to render the page. The html parser could be a plugin : that +way we could have a pdf-plugin, a rtf-plugin ... that would be nice. +But that's not what we are doing : we are doing an html browser, and +html source is intended to be in the browser, not sent to plugins. +The way Jorge defined plugins (that can change) is clean and simple : a +plugin call looks like a link ("dpi://myplugin"), some datas are sent +(name=value type), the plugin sends back an html page (and possibly ask +dillo to update its menus, but there's no protocol for that yet, though +I'm working on it). That's it. There's no two-way interaction between +dillo and the plugins. There is no possibility for a plugin to ask dillo +about its internals, such as page source, history. +Albeit your module/plugin idea is interesting, that would mean a big +rewrite in dillo's whole html parsing and plugin system (I know, +it's not written yet) just to avoid small changes in dillo's menus and +anchor (and H1..h6) parsing. +In a nutshell, I think it's better and easier to keep these things in +dillo, until we define (not soon) a clear mecanisme for external +modules, which aren't plugins. + +(man, _that's_ a long answer to a not very useful question ;-) + +---------------------------------- +Eric GAUDET +Le 25-Aug-2000 a 19:02:34 +---------------------------------- + + + +Re: [Dillo-dev]java in dillo + +From: Sebastian Geerken - 2000-08-25 09:58 + +Sean 'Shaleh' Perry wrote: +> +> On 25-Aug-2000 Eric GAUDET wrote: +> > Hi again, +> > Anybody working on applets in Dillo ? I wondered if it was possible for +> > dillo to launch the 'appletviewer' program (from a separate JDK) and +> > then "swallow" its windows to render the initial html page (just like +> > wharf, dock or gnome/kde pannel do with dockable applets). +> > +> > I don't think I'll see that soon, but that could be fairly doable. +> > +> +> I doubt this will work. swallowed apps work because of an agreement between +> the app and the window manager / panel. + +Furthermore, communication between applet and browser (class +AppletContext) will not be possible. Perhaps Kaffe or Japhar can be +used somehow. + +> What we probably need to do is have a +> widget which is an arbitrary window. Then java, javascript, embedded +> , animations, etc can be placed in this widget. + +Perhaps look at GtkSocket/GtkPlug. They provide a mechanism to embed +windows created by other programs. + +Sebastian + + + +Re: [Dillo-dev]Anchor : feature wish + +From: Sebastian Geerken - 2000-08-25 09:58 + +Eric GAUDET wrote: +> Hi, +> I just thought about one (new idea?) feature about anchors : would it +> be possible to list them in a menu entry (Named "Chapters"? "Index"? +> "Content"?). Doing that, each time a page is loaded, this menu entry +> would be updated and the user could conveniently "jump" to anchors in +> the page without scrolling. +> +> What do you think ? + +That would be possible. But I think a menu of the anchors in a page is +not very useful. Better would be to list all the

...

. That +could also be possible by adding "pseudo anchors". If you get a tag +which position is interesting, you add a DW_PAGE_CONTENT_ANCHOR "@id" +or so, where id is a unique number (unique in the page). + +Another idea: What about a mechanism to let the user ("user" is anyone +who does not changes the sources of dillo ;-) write such things. +Perhaps plugins? The plugin transmits to dillo what is interesting for +it (e.g. tags "h1", ..., "h6"), and dillo gives a unique id for +referring to the tags to the plugin. When a user clickes on an item in +the plugin's list, the plugin sends a url to dillo. + +Sebastian + + + +RE: [Dillo-dev]java in dillo + +From: Sean 'Shaleh' Perry - 2000-08-25 04:17 + +On 25-Aug-2000 Eric GAUDET wrote: +> Hi again, +> Anybody working on applets in Dillo ? I wondered if it was possible for +> dillo to launch the 'appletviewer' program (from a separate JDK) and +> then "swallow" its windows to render the initial html page (just like +> wharf, dock or gnome/kde pannel do with dockable applets). +> +> I don't think I'll see that soon, but that could be fairly doable. +> + +I doubt this will work. swallowed apps work because of an agreement between +the app and the window manager / panel. What we probably need to do is have a +widget which is an arbitrary window. Then java, javascript, embedded +, animations, etc can be placed in this widget. + + + +[Dillo-dev]java in dillo + +From: Eric GAUDET - 2000-08-25 04:10 + +Hi again, +Anybody working on applets in Dillo ? I wondered if it was possible for +dillo to launch the 'appletviewer' program (from a separate JDK) and +then "swallow" its windows to render the initial html page (just like +wharf, dock or gnome/kde pannel do with dockable applets). + +I don't think I'll see that soon, but that could be fairly doable. + +---------------------------------- +Eric GAUDET +Le 25-Aug-2000 a 13:06:05 +---------------------------------- + + + +[Dillo-dev]Anchor : feature wish + +From: Eric GAUDET - 2000-08-25 04:06 + +Hi, +I just thought about one (new idea?) feature about anchors : would it +be possible to list them in a menu entry (Named "Chapters"? "Index"? +"Content"?). Doing that, each time a page is loaded, this menu entry +would be updated and the user could conveniently "jump" to anchors in +the page without scrolling. + +What do you think ? + +---------------------------------- +Eric GAUDET +Le 25-Aug-2000 a 12:59:58 +---------------------------------- + + + +[Dillo-dev]another fun test site + +From: Sean 'Shaleh' Perry - 2000-08-24 20:09 + +validator.w3.org + +This takes a web site and shows how valid its HTML is. Also can include the +parse tree of the document. + +dillo currently fails to lay out the results properly. + + + +[Dillo-dev]Dw -> Gtk + +From: Sebastian Geerken - 2000-08-24 16:34 + +Hi! + +There is a problem (and an idea on its solution) with Gtk+: + +A rule of Gtk+ is, that widgets have to deal with any size allocation, +but some of the Dw widgets depend on a more complicated size +negotiation, which is currently done by a_Dw_size_nego_x, e. g.: + +- DwPage, which should always allocate the size needed to display all +the text, +- the not-yet-written table widget, comparable to DwPage, and +- DwImage's with relative size (?). + +I've thought about several ways, the one I prefer is this: + +Such widgets do not simply accept the GtkAllocation in +gtk_xxx_size_allocate, but correct it before storing it in +widget->allocation. The standard Gtk+ containers do not refer to these +corrected allocations, but to those they have calculated for there +children, so you get either unintended spaces or overlapping widgets. +So, dillo's new containers (e. g. the table) should use these +"reallocations". + +I've tested it by writing a few useless widgets, and it works. + +Some alternatives which have also come to my mind: + +- Derive all widgets from one base widget GtkDwWidget which has a +functionality similar to a_Dw_size_nego_x. A container could do some +thing like this: + +if (GTK_IS_DW_WIDGET (child)) { +/* use the functionality of GtkDwWidget */ +} else { +/* standard size allocation */ +} + +Since Gtk+ does not provide multiple inheritance, there will be the +problem which base class to use for GtkDwBase. E.g., should images be +containers? Deriving from and so reusing other Gtk+ widgets will be +impossible. + +- Children resize themselves on a size allocation. This is somehow +possible (I once wrote something like this), but this will result in a +horrible overhead. + +Comments? + +Sebastian + + + +[Dillo-dev]still some concerns about HR tag + +From: Eric GAUDET - 2000-08-23 13:46 + +Hi, I just tested the HR "bug-fix" in dillo v0.2.4 : the line's width +is the page's width all right. But the horizontal page slider is still +there !!! (you can scroll to see the emptyness in the right) + +---------------------------------- +Eric GAUDET +Le 23-Aug-2000 a 22:42:31 +"Si la japonaise est la négation la plus aboslue de la femme, +elle est aussi la négation la plus absolue de la beauté grecque." +(Louis Martin, l'Anglais est-il un juif ?, 1895) +---------------------------------- + + + +[Dillo-dev]style sheets + +From: Sean 'Shaleh' Perry - 2000-08-23 07:02 + +So, was driving home tonight and an idea hit me. + +Style sheets are meant to be cascading (they stack). So, we can implement user +preferences as local style sheets which come first (highest) or last based on +settings. The allow_whitebg becomes a simple style sheet line. + +Properly implementing font and what not will require some ground work and if I +am doing that, I may as well look to the future. + +Comments? + + + +RE: [Dillo-dev]other requests + +From: Sean 'Shaleh' Perry - 2000-08-23 06:59 + +> +> And the same thing when going to http://www.mysite.org/ and the browser +> popups-up a window asking for your login and password. (the http side +> is the same, basically you have to encode in base64 the string +> "user:password" and send that in the http request) +> + +right + +Playing with right now and pondering style sheets. Need to set up a +local http server to play with http auth, cgi, and the like. + + + +RE: [Dillo-dev]other requests + +From: Eric GAUDET - 2000-08-23 03:35 + +Le 22-Aug-2000, on m'a dit : +> > +> > I mean http auth, as in http://user:password@ww.../ +> > +> +> the URL parser needs to understand this. Then the proper http send +> mechanism +> needs to be used. I do not think this would be too hard. Now I +> have two +> reasons to read the HTTP spec. +> + +And the same thing when going to http://www.mysite.org/ and the browser +popups-up a window asking for your login and password. (the http side +is the same, basically you have to encode in base64 the string +"user:password" and send that in the http request) + +---------------------------------- +Eric GAUDET +Le 23-Aug-2000 a 12:31:30 +---------------------------------- + + + +[Dillo-dev]currently working on + +From: Sean 'Shaleh' Perry - 2000-08-23 01:39 + +I have an initial implementation of put together. It currently only +handles the color attribute, but more to come. My current problem is that when +the tag is popped, the color is not reset. I am confused, the rest of the font +like tags (bold, cite) clean up after themselves by simply popping their tag. +Will get it when I get a chance. + + + +Re: [Dillo-dev]0.2.4 release + +From: Sebastian Geerken - 2000-08-22 22:27 + +Hi, Sean, + +Sean 'Shaleh' Perry wrote: +> +> > +> > 2. The better way: Leave "not-reloading" enabled, but push the url's +> > on the stack "by hand". See the "else" part of "if (must_load)". I +> > tried to implement it, bud didn't understand how. I think it is done +> > in a_Nav_expect_done, but calling it (or a modified version of it) +> > didn't work. This is an other point worth to improve. +> > +> +> enclosed is the beginnings of this patch. If I go to foo.html, then follow +> foo.html#link, then hit back, I get to foo.html. However if I go to +> foo.html#second from foo.html#link, then hit back I still go to foo.html. Not +> quite sure how the anchor system works. Maybe you can take the code and go +> from there. + +My changes in the Nav module only consist of a few lines. Most of my +code is in GtkDwScroller and DwPage. Furthermore, I did not understand +the navigation mechanism very good, so perhaps someone else should +work on this problem. + +BTW: I sent Jorge some documentation, I think, he should include it +into the release. + +> The patch is longer than it needs to be because I moved Nav_open_url to the end +> of the file and places a declaration at the top so the other functions know +> about it. This mimics the layout of the other source modules. + +What about including "nav.h" in "nav.c"? That would also let the +compiler check the function prototypes against there definitions. + +> I think there is something wrong with calling a_Foo_bar() in module Foo. + +Yes, propably there should be a seperate function, which is called by +Nav_open_url and a_Nav_expect_done. + +Sebastian + + + +Re: [Dillo-dev]weird bug in anchor code + +From: Sebastian Geerken - 2000-08-22 21:24 + +Jorge Arellano Cid wrote: +> +> Sean, +> +> > http://www.gphoto.org/news.html +> > +> > The GNU Public License link points to http://www.gnu.org, but dillo +> > thinks it points to http://www.gphoto.org. +> +> Fixed! (BUG #79) + +I wrote: +> [...] + +Ok, 5 minutes of wasted time. ;-) + +Sebastian + + + +Re: [Dillo-dev]weird bug in anchor code + +From: Sebastian Geerken - 2000-08-22 21:19 + +Sean 'Shaleh' Perry wrote: +> +> http://www.gphoto.org/news.html +> +> The GNU Public License link points to http://www.gnu.org, but dillo +> thinks it points to http://www.gphoto.org. + +The html file looks like this: + + + +When there are whitespaces after the attribute name, Html_get_attr +returns an empty string, and so a_Url_resolve_relative returns the +wrong url. + +Sebastian + + + +Re: [Dillo-dev]weird bug in anchor code + +From: Jorge Arellano Cid - 2000-08-22 20:50 + +Sean, + + +> http://www.gphoto.org/news.html +> +> The GNU Public License link points to http://www.gnu.org, but dillo +> thinks it points to http://www.gphoto.org. + +Fixed! (BUG #79) + + + +Re: [Dillo-dev]0.2.4 release + +From: Sean 'Shaleh' Perry - 2000-08-22 19:22 + +Attachments: nav.patch + +> +> 2. The better way: Leave "not-reloading" enabled, but push the url's +> on the stack "by hand". See the "else" part of "if (must_load)". I +> tried to implement it, bud didn't understand how. I think it is done +> in a_Nav_expect_done, but calling it (or a modified version of it) +> didn't work. This is an other point worth to improve. +> + +enclosed is the beginnings of this patch. If I go to foo.html, then follow +foo.html#link, then hit back, I get to foo.html. However if I go to +foo.html#second from foo.html#link, then hit back I still go to foo.html. Not +quite sure how the anchor system works. Maybe you can take the code and go +from there. + +The patch is longer than it needs to be because I moved Nav_open_url to the end +of the file and places a declaration at the top so the other functions know +about it. This mimics the layout of the other source modules. + +I think there is something wrong with calling a_Foo_bar() in module Foo. + + + +RE: [Dillo-dev]other requests + +From: Sean 'Shaleh' Perry - 2000-08-22 18:10 + +> +> I mean http auth, as in http://user:password@ww.../ +> + +the URL parser needs to understand this. Then the proper http send mechanism +needs to be used. I do not think this would be too hard. Now I have two +reasons to read the HTTP spec. + + + +Re: [Dillo-dev]the source viewer widget + +From: Sean 'Shaleh' Perry - 2000-08-22 18:08 + +On 22-Aug-2000 Sebastian Geerken wrote: +> Sean 'Shaleh' Perry wrote: +>> I tried to add horizontal scrollbars to the GtkText widget in +>> a_Commands_viewsource(). For whatever reason, they are not used. Passing +>> them +>> into the constructor of GtkText has no effect. Even with the policy set to +>> ALWAYS the scrollbar is shown but does not actually function. +> +> I assume you want to enable horizontal scrolling and disable line +> wrapping? +> +> You can do this by calling gtk_text_set_line_wrap (text, FALSE), but +> horizontal adjustment isn't working correctly now. This is a bug of +> Gtk+, and it will propably fixed soon (or perhaps is already), so you +> should not care about it (or fix this bug in Gtk+ :-). +> + +well i feel better. I did all the line_wrap, word_wrap calls. + + + +RE: [Dillo-dev]0.2.4 release + +From: Sean 'Shaleh' Perry - 2000-08-22 18:08 + +On 22-Aug-2000 Jorge Arellano Cid wrote: +> +> +> On Mon, 21 Aug 2000, Sean 'Shaleh' Perry wrote: +> +>> we need a "DNS not found" message in the GUI +>> +>> If the DNS resolver has problems, the user has no feed back on why +> +> Actually there's a message in the status window. +> Maybe not enough, but not nonexistent. +> + +yesterday I could not reach gtk.org, lots of IO_Abort messages on a terminal. +But the GUI gave no indication. I hit Stop, then tried again and I could not +tell it was doing anything except for more abort messages on the term. + + + +Re: [Dillo-dev]Dw vs. Gtk + +From: Sebastian Geerken - 2000-08-22 17:09 + +Jorge Arellano Cid wrote: +> If you want to join in this effort, that's all I need to get +> started. + +If it's ok, I'll start with DwPage, because I have some ideas on it +(I'll post to the list when something gets useful). + +(Starting with DwPage doesn't make much sense, since I'll have to +deactivate the adding of Dw widgets. ;-) + +Sebastian + + + +RE: [Dillo-dev]0.2.4 release + +From: Jorge Arellano Cid - 2000-08-22 14:36 + +On Mon, 21 Aug 2000, Sean 'Shaleh' Perry wrote: + +> we need a "DNS not found" message in the GUI +> +> If the DNS resolver has problems, the user has no feed back on why + +Actually there's a message in the status window. +Maybe not enough, but not nonexistent. + +Jorge.- + + + +Re: [Dillo-dev]Dw vs. Gtk + +From: Sebastian Geerken - 2000-08-22 13:58 + +Jorge Arellano Cid wrote: +> [...] +> > I'm interrested in implementing tables, and the simplest approach is +> > propably nesting of DwPage's. I have already played around with it +> > (nothing directly useful, but only to test how it could work), and got +> > results which are not what I intended, but --- you can see something +> > ;-) +> +> Yes, but we have Dw widgets in the way (some not instantiable +> some not nesting well). + +No, I meant something different: I extended DilloHtml by a stack for +DwPage's, so that parts of the same html doc can be written in +different DwPage's (this is needed for tables). This works mainly, so +I think it's a useful approach. + +Sebastian + + + +Re: [Dillo-dev]0.2.4 release + +From: Sebastian Geerken - 2000-08-22 13:08 + +Sean 'Shaleh' Perry wrote: +> The back option after following an anchor takes me to the last page loaded, +> not +> the location I was at before I followed the anchor. + +There are two different ways to change it: + +1. Force reloading in Nav_open_url. (Set a "must_reload = TRUE" before +"if (must_load)" or so.) Then the page will be reloaded always, so +*all* url's will be pushed on the navigation stack. (Reloading will be +quite fast. :-) + +2. The better way: Leave "not-reloading" enabled, but push the url's +on the stack "by hand". See the "else" part of "if (must_load)". I +tried to implement it, bud didn't understand how. I think it is done +in a_Nav_expect_done, but calling it (or a modified version of it) +didn't work. This is an other point worth to improve. + +Sebastian + + + +Re: [Dillo-dev]the source viewer widget + +From: Sebastian Geerken - 2000-08-22 13:08 + +Sean 'Shaleh' Perry wrote: +> I tried to add horizontal scrollbars to the GtkText widget in +> a_Commands_viewsource(). For whatever reason, they are not used. Passing +> them +> into the constructor of GtkText has no effect. Even with the policy set to +> ALWAYS the scrollbar is shown but does not actually function. + +I assume you want to enable horizontal scrolling and disable line +wrapping? + +You can do this by calling gtk_text_set_line_wrap (text, FALSE), but +horizontal adjustment isn't working correctly now. This is a bug of +Gtk+, and it will propably fixed soon (or perhaps is already), so you +should not care about it (or fix this bug in Gtk+ :-). + +Sebastian + + + +RE: [Dillo-dev]other requests + +From: Eric GAUDET - 2000-08-22 05:54 + +Le 22-Aug-2000, on m'a dit : +> +> On 22-Aug-2000 Eric GAUDET wrote: +> > Le 22-Aug-2000, on m'a dit : +> >> animated gif support +> >> +> >> improved font support +> >> +> >> cookies +> >> +> > +> > And basic html authetification too. +> > +> +> do you mean SSL kinda stuff? http auth? or actual "this is good +> HTML"? +> + +I mean http auth, as in http://user:password@ww.../ + +---------------------------------- +Eric GAUDET +Le 22-Aug-2000 a 14:53:52 +---------------------------------- + + + +[Dillo-dev]weird bug in anchor code + +From: Sean 'Shaleh' Perry - 2000-08-22 05:28 + +http://www.gphoto.org/news.html + +The GNU Public License link points to http://www.gnu.org, but dillo +thinks it points to http://www.gphoto.org. + + + +RE: [Dillo-dev]other requests + +From: Sean 'Shaleh' Perry - 2000-08-22 05:13 + +On 22-Aug-2000 Eric GAUDET wrote: +> Le 22-Aug-2000, on m'a dit : +>> animated gif support +>> +>> improved font support +>> +>> cookies +>> +> +> And basic html authetification too. +> + +do you mean SSL kinda stuff? http auth? or actual "this is good HTML"? + + + +RE: [Dillo-dev]other requests + +From: Eric GAUDET - 2000-08-22 05:10 + +Le 22-Aug-2000, on m'a dit : +> animated gif support +> +> improved font support +> +> cookies +> + +And basic html authetification too. + +---------------------------------- +Eric GAUDET +Le 22-Aug-2000 a 14:07:36 +---------------------------------- + + + +[Dillo-dev]other requests + +From: Sean 'Shaleh' Perry - 2000-08-22 04:30 + +animated gif support + +improved font support + +cookies + + + +Re: [Dillo-dev]GTK 1.3.1 + +From: Sean 'Shaleh' Perry - 2000-08-22 04:28 + +> May I suggest one of the following: +> +> * BUG#27: Client side image maps +> * BUG#62: Horizontal rules (50% already done) +> * BUG#60: Png's transparent backgrounds +> *
tag? +> + +div is only truly useful once we support style sheets. Until then it has no +meaning (it is like event boxes without events otherwise). + +Another would be to make dillo properly display numbered lists. Currently too +many newlines are shown. Compare netscape / mozilla / konqueror / whatever. + +Also, if code has: + +foo
+
+ +the first br is used, any immediately following are ignored. + + + +RE: [Dillo-dev]0.2.4 release + +From: Sean 'Shaleh' Perry - 2000-08-22 00:31 + +On 21-Aug-2000 Jorge Arellano Cid wrote: +> +> Hi! +> +> Dillo-0.2.4 is ready for download! +> +> The guys at sourceforge managed to complicate file releases +> even more; I hope they change it soon... +> + +The back option after following an anchor takes me to the last page loaded, not +the location I was at before I followed the anchor. + + + +RE: [Dillo-dev]0.2.4 release + +From: Sean 'Shaleh' Perry - 2000-08-22 00:27 + +On 21-Aug-2000 Jorge Arellano Cid wrote: +> +> Hi! +> +> Dillo-0.2.4 is ready for download! +> +> The guys at sourceforge managed to complicate file releases +> even more; I hope they change it soon... +> + +we need a "DNS not found" message in the GUI + +If the DNS resolver has problems, the user has no feed back on why + + + +[Dillo-dev]0.2.4 release + +From: Jorge Arellano Cid - 2000-08-21 16:51 + +Hi! + +Dillo-0.2.4 is ready for download! + +The guys at sourceforge managed to complicate file releases +even more; I hope they change it soon... + +Anyway, the file is there. + +Enjoy! +Jorge.- + + + +Re: [Dillo-dev]Dw vs. Gtk + +From: Jorge Arellano Cid - 2000-08-21 01:28 + +Sebastian, + +> What is the current state in: +> +> 1. the question "Replace the Dw widgets by Gtk+ widgets or not?", and +> 2. tables? + +Basically what I wrote in 'DilloWidget.txt' (within /doc dir). +I was expecting some help to start porting back Dw to GTK+ +(unless a better approach was pointed out). + +> I'm interrested in implementing tables, and the simplest approach is +> propably nesting of DwPage's. I have already played around with it +> (nothing directly useful, but only to test how it could work), and got +> results which are not what I intended, but --- you can see something +> ;-) + +Yes, but we have Dw widgets in the way (some not instantiable +some not nesting well). + +> There should propably a widget for tables + +Of course! + +> [...] + +Looks quite similar to DilloWidget.txt! + +> So, what is currently planned on this topic? + +A question to Peter Mattis for advice on the table widget +implementation, and to start by porting back Dw to GTK+, and +finally, to work the table widget. + +If you want to join in this effort, that's all I need to get +started. +BTW: I wrote the widget documentation with a view to help it +happen ;-) + + +Jorge.- + + + +Re: [Dillo-dev]GTK 1.3.1 + +From: Jorge Arellano Cid - 2000-08-21 01:17 + +Jörgen, + +> Hi all! +> +> I recently downloaded the devel branch of GTK and tried it with Dillo. I'm +> pleased to see that the exposure problems are not there anymore. I could +> remove the event boxes from the checkboxes and radio buttons. + +!!??? +Funny, I always thought that the problem was with Dw. Even +more, the event boxes were designed for widgets lacking a window, +just a the ones we had. + +Unless the new GTK+ provides a default window for every widget, +I'm a little puzzled with this. + +> There were no problems porting the code either. + +Let's keep the event boxes for now (it will be a long time +until updating makes 1.3.1 the default GTK+). + +> PS. I really need something to code on instead of writing stuff like this +> ;-) + +May I suggest one of the following: + +* BUG#27: Client side image maps +* BUG#62: Horizontal rules (50% already done) +* BUG#60: Png's transparent backgrounds +*
tag? + + +Jorge.- + + + +Re: [Dillo-dev]dillo can't read pngs on gphoto.org + +From: Jorge Arellano Cid - 2000-08-21 01:16 + +Sean, + +> So, I was making dillo ignore the text between SCRIPT tags (it puts them in the +> stash, then ignores the stash) + +Good! + +> I was looking for test sites. gphoto.org is a +> good one. It uses roll overs and what not for fancy browsing. While looking +> around the site I notice that dillo often fails to render the pngs it find +> there. Anyone mind looking at this and suggesting why? + +This is BUG#4. +I went to gphoto with 0.2.4 and everything was OK. + +Anyway, I'm planning to release 0.2.4 tomorrow in the morning! + +Jorge.- + + + +[Dillo-dev]the source viewer widget + +From: Sean 'Shaleh' Perry - 2000-08-21 00:27 + +I tried to add horizontal scrollbars to the GtkText widget in +a_Commands_viewsource(). For whatever reason, they are not used. Passing them +into the constructor of GtkText has no effect. Even with the policy set to +ALWAYS the scrollbar is shown but does not actually function. + + + +[Dillo-dev]dillo can't read pngs on gphoto.org + +From: Sean 'Shaleh' Perry - 2000-08-20 21:45 + +So, I was making dillo ignore the text between SCRIPT tags (it puts them in the +stash, then ignores the stash) I was looking for test sites. gphoto.org is a +good one. It uses roll overs and what not for fancy browsing. While looking +around the site I notice that dillo often fails to render the pngs it find +there. Anyone mind looking at this and suggesting why? + +On the SCRIPT reading, the stash is a great thing. When we get around to +adding script support, we just pass the stash to the interpreter. + + + +[Dillo-dev]GTK 1.3.1 + +From: Jörgen Viksell - 2000-08-19 23:32 + +Hi all! + +I recently downloaded the devel branch of GTK and tried it with Dillo. I'm +pleased to see that the exposure problems are not there anymore. I could +remove the event boxes from the checkboxes and radio buttons. +There were no problems porting the code either. + +PS. I really need something to code on instead of writing stuff like this +;-) + +// Jörgen +________________________________________________________________________ +Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com + + + +Re: [Dillo-dev]Question + +From: Jorge Arellano Cid - 2000-08-19 20:22 + +Okki, + +> Hi, +> +> Can we have a CVS (read only ?) acces for the sources ? +> +> Thanx + +This is a good idea, and we have the possibility to set it up +in sourceforge. The problem is with me, not savvy in CVS and too +busy to be in charge of it. Anyway, if the volunteer arises, no +problem. + +Jorge.- + + + +RE: [Dillo-dev]Misc. answers. + +From: Jorge Arellano Cid - 2000-08-19 20:21 + +Sean, + +> >> Alternatively, what do you think about getting rid of the location +> >> window and Ctrl-L fucing the cursor to the location bar? + +Just as Andrew pointed out, the idea is to move the text cursor + +> one use most browsers give their location window is a file chooser so it is +> easy to browse local html directories, like those in library docs. dillo +> currently has no way to do this and removing the location window would give no +> obvious place to put this functionality. + +There's a way: File | Open File. (Ctrl-O) +Unfortunately, the shortcut-keys code is somewhat buggy and +needs a revision. + +Anyway, you can type 'file:' in the location bar. + +Maybe I'll let everyone test the feature with Ctrl-N (New), +having the same functionallity of the "NEW" button. + +Jorge.- + + + +Re: [Dillo-dev]I18n + +From: Jorge Arellano Cid - 2000-08-19 20:21 + +Sebastian, + +> Jorge Arellano Cid wrote: +> > Personally, I hate internationalization. (This is just my +> > personal feel on the subject). +> > [...] +> +> I, personally, cannot confirm this, my experiences with traductions +> (into german) are quite good. + +Germans are serious people! :-) + +> [...] +> Of course, any other tasks, mainly writing the .po files (the message +> tables), currently have very low priority. + +Let's work the code base for tables. I'll answer your post ASAP +(basically I also think better to lean on GTK+). + +> > I think that if we +> > manage to provide those "mission critical" ones, a growing +> > community will provide patches for the others; but if we fail +> > with the critical ones, the whole project could get stuck and ... +> +> >From this point of view, you are right: after a specific point +> (assumed it will be reached), productivity somehow grows. (Why is it +> not possible to use "quasi" as an adverb in english? ;-) + +Hmmmm, sometimes they use 'almost', and certainly some of those +prefer to express it in a ironic way! ;) + + +Jorge.- + + + +RE: [Dillo-dev]Dw vs. Gtk + +From: Eric GAUDET - 2000-08-19 16:26 + +Le 19-Aug-2000, on m'a dit : +> I'm interrested in implementing tables, +... +> It could be implemented as Dw or as Gtk+ widget. The latter would +> have following effects: +> +> - It would be simpler to write, since I know Gtk+ better that Dw +> (and there are much more examples :-) +> +.... +> +> So, what is currently planned on this topic? +> +> Sebastian +> + +I guess you're elected to implement tables in dillo : congratulations +;-) + +---------------------------------- +Eric GAUDET +Le 20-Aug-2000 a 01:22:35 +---------------------------------- + + + +[Dillo-dev]Dw vs. Gtk + +From: Sebastian Geerken - 2000-08-19 09:26 + +What is the current state in: + +1. the question "Replace the Dw widgets by Gtk+ widgets or not?", and +2. tables? + +I'm interrested in implementing tables, and the simplest approach is +propably nesting of DwPage's. I have already played around with it +(nothing directly useful, but only to test how it could work), and got +results which are not what I intended, but --- you can see something +;-) + +There should propably a widget for tables (I think it should be +written from scratch, since the Gtk+ containers do not exactly provide +the functionality for this problem). It could be implemented as Dw or +as Gtk+ widget. The latter would have following effects: + +- It would be simpler to write, since I know Gtk+ better that Dw (and +there are much more examples :-) + +- Perhaps the table widget should itself contain Gtk+ widgets. So, +until DwPage gets gtk'd (or not), there is a wrapper widget needed as +container for DwPage. Currently, only GtkDwView may contain a Dw +widget, but cannot be used for this case. + +- One function of Dw is not provided by Gtk+: changing only one +dimension (normally the width), which then affects the other. This had +to be added. + +- The well known problems would be eliminated. + +So, what is currently planned on this topic? + +Sebastian + + + +Re: [Dillo-dev]I18n + +From: Sebastian Geerken - 2000-08-19 09:26 + +Hi, Jorge! + +Jorge Arellano Cid wrote: +> Personally, I hate internationalization. (This is just my +> personal feel on the subject). +> +> This mostly because: +> +> - I understand english! +> +> - Living in a spanish-speaking country, had brought several +> nasty experiences related with it. Bad traductions, +> missconfigured systems, and impossible to understand spanish +> books. +> [...] + +I, personally, cannot confirm this, my experiences with traductions +(into german) are quite good. But I think this is no point. (You are +free to unset your $LANG variable ;-) + +> I can also see several tasks (like this one, download +> implementation, etc), that can be added easily, my main concerns +> are not with them but with those that can affect the whole +> project (as not being able to render tables). + +I only meant to prepare dillo, i. e. only include "_" and "_N". I +personally think, it should always be included from the beginning, +since it gets quite hard to add it to an existing project. Then use of +"_" and "_N" is quite simple (assumed you remember it ;-). + +Of course, any other tasks, mainly writing the .po files (the message +tables), currently have very low priority. + +> I think that if we +> manage to provide those "mission critical" ones, a growing +> community will provide patches for the others; but if we fail +> with the critical ones, the whole project could get stuck and ... + +From this point of view, you are right: after a specific point +(assumed it will be reached), productivity somehow grows. (Why is it +not possible to use "quasi" as an adverb in english? ;-) + +Sebastian + + + +RE: [Dillo-dev]Misc. answers. + +From: Sean 'Shaleh' Perry - 2000-08-19 00:39 + +>> +>> Alternatively, what do you think about getting rid of the location +>> window and Ctrl-L fucing the cursor to the location bar? +> +> Cool! +> +> Is it OK with you Sean? +> + +one use most browsers give their location window is a file chooser so it is +easy to browse local html directories, like those in library docs. dillo +currently has no way to do this and removing the location window would give no +obvious place to put this functionality. + + + +[Dillo-dev]Question + +From: Okki - 2000-08-18 22:46 + +Hi, + +Can we have a CVS (read only ?) acces for the sources ? + +Thanx + + + +RE: [Dillo-dev]Misc. answers. + +From: Andrew McPherson - 2000-08-17 19:35 + +On Thu, 17 Aug 2000, Sean 'Shaleh' Perry wrote: + +> +> On 16-Aug-2000 Jorge Arellano Cid wrote: +> > +> > Eric, +> > +> >> Le 15-Aug-2000, on m'a dit : +> >> > > Anyway, we can get rid of the open +> >> > > location window (because the location bar provides the same +> >> > > functionality). +> >> > > Comments? +> >> > > +> >> > +> >> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and +> >> > never move +> >> > my mouse. +> >> > +> >> +> >> Alternatively, what do you think about getting rid of the location +> >> window and Ctrl-L fucing the cursor to the location bar? +> > +> > Cool! +> > +> > Is it OK with you Sean? +> > +> +> Hey, it's your project. I was always told to never move the mouse. How about +> testing this feature and leaving the other code #if 0'ed out? +> + +Sorry to jump in on the conversation. I haven't posted anything in a +while. + +I think he means move the text cursor to the location bar, not the mouse +pointer. Moving the mouse pointer would be a bit strange- it reminds me of +hitting the "start menu" button on Windows keyboards. Ugh. Moving the text +cursor would be nice, though, as long as it selected the current location. +That way I could still do Ctl-L, then type, without having to manually +delete the existing location. + +Just my $.02 + +-Andrew + + + +Re: [Dillo-dev]I18n + +From: Sean 'Shaleh' Perry - 2000-08-17 18:58 + +> +> I can also see several tasks (like this one, download +> implementation, etc), that can be added easily, my main concerns +> are not with them but with those that can affect the whole +> project (as not being able to render tables). I think that if we +> manage to provide those "mission critical" ones, a growing +> community will provide patches for the others; but if we fail +> with the critical ones, the whole project could get stuck and ... +> + +the html renderer should render the page in whatever language it was told the +page was. More on this as I (we) add tag and HTML 4.x support. + +The part we care about for code is the actual gui -- i.e. menus, buttons, etc. + + + +RE: [Dillo-dev]Misc. answers. + +From: Sean 'Shaleh' Perry - 2000-08-17 18:53 + +On 16-Aug-2000 Jorge Arellano Cid wrote: +> +> Eric, +> +>> Le 15-Aug-2000, on m'a dit : +>> > > Anyway, we can get rid of the open +>> > > location window (because the location bar provides the same +>> > > functionality). +>> > > Comments? +>> > > +>> > +>> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and +>> > never move +>> > my mouse. +>> > +>> +>> Alternatively, what do you think about getting rid of the location +>> window and Ctrl-L fucing the cursor to the location bar? +> +> Cool! +> +> Is it OK with you Sean? +> + +Hey, it's your project. I was always told to never move the mouse. How about +testing this feature and leaving the other code #if 0'ed out? + + + +Re: [Dillo-dev]I18n + +From: Jorge Arellano Cid - 2000-08-16 17:11 + +Sebastian, + +> Hi! +> +> When dillo is supposed to be used by end users (in the future ;-), +> perhaps we should start to internationalize it. Soon, because it gets +> more difficult the more the project advances. From the view of a +> programmer, gettext is quite simple to use (and can easily be +> deactivated on systems on which it is not supported). +> [...] +> What do you think about this? + +Personally, I hate internationalization. (This is just my +personal feel on the subject). + +This mostly because: + +- I understand english! + +- Living in a spanish-speaking country, had brought several +nasty experiences related with it. Bad traductions, +missconfigured systems, and impossible to understand spanish +books. + +............................................................... +For instance: + +'case sensitive' : "sensible al caso". (awful!) +("hace diferencia entre mayúsculas y +minúsculas" is the right one) + +'Save' : 'Salvar' (to escape danger! instead of 'Grabar') + +'Do you want to delete (Y/N)' +'Desea borrar el archivo (S/N)' +You got to answer 'Y' to get the job done! + +Not to mention the big mess with Hotkeys (not mnemonic anymore) + +Translated manpages on missconfigured terminals: +'había un niño' becomes 'haba un nio' +(this is a big problem when you're not root) + +Finally, when traductions are larger (in characters) than the +original sentences, they often render truncated. +............................................................... + + +I'm not against been understood in other languajes, is just +that my experiences are bad with it, except when the SW authors +include their own support (i.e. they provide the translations, +menu arrangements, new hotkeys and things like that). + +I can also see several tasks (like this one, download +implementation, etc), that can be added easily, my main concerns +are not with them but with those that can affect the whole +project (as not being able to render tables). I think that if we +manage to provide those "mission critical" ones, a growing +community will provide patches for the others; but if we fail +with the critical ones, the whole project could get stuck and ... + + +Jorge.- + +-- + +Ps: The guys from Intel (Taiwan) told me that dillo was ported +to the StrongARM-110 and StrongARM-11x0 boards. + + + +RE: [Dillo-dev]Misc. answers. + +From: Jorge Arellano Cid - 2000-08-16 17:11 + +Eric, + +> Le 15-Aug-2000, on m'a dit : +> > > Anyway, we can get rid of the open +> > > location window (because the location bar provides the same +> > > functionality). +> > > Comments? +> > > +> > +> > please keep it. This allows me to "Ctrl-L, http://foo, enter" and +> > never move +> > my mouse. +> > +> +> Alternatively, what do you think about getting rid of the location +> window and Ctrl-L fucing the cursor to the location bar? + +Cool! + +Is it OK with you Sean? + +Jorge.- + + + +Re: [Dillo-dev]Html Parser + +From: Jorge Arellano Cid - 2000-08-16 17:10 + +Sebastian, + +> Is there any reason for a separate function list F_list in html.c. Why +> are the functions not directly integrated in the Tags list (static +> TagInfo Tags[NTAGS])? + +Once upon a time there was one, but I don't remember it now! ;) + +Sean provided me with a patch for that, so consider it done. + +Jorge.- + + + +RE: [Dillo-dev]Misc. answers. + +From: Jorge Arellano Cid - 2000-08-16 17:10 + +Sean, + +> In previous projects, smaller patches over time were easier to get applied +> than one giant "I changed everything" patch. But each group is different. + +My point is that as each patch modified the former, I had to +study them all. (And YES, I also prefer small patches). + +> [...] +> > I found a better place that needs a single call to the entity +> > parsing function. Not implemented yet, but if it works, I'll keep +> > it. +> > +> +> that would be cool, I have not quite understood all that is html.c + +Well, it seems I'll keep the old scheme. The entities parsing +could have been handled in Html_write, but that requires to show +unsupported tags as words (not bad, but the standar advices to +ignore them). + +> >> loading large images is rather slow, I noticed this on screen +> >> shot pages +> +> > Maybe due to ... +> +> nope, simply going to some guys web page with a 1200x100 screen shot. + +I guess you are comparing the time with another browser... +There's a tricky way to speed up image transfers on slow +networks: If you get a Content-Length tag from the web server, +you can use HTTP1.1 to open new connections to start retrieving +partial chunks of unreceived data... + +I remember that sometime ago I started donloading a big image +with Netscape and after a while, started dillo to do the same; +dillo finished first and Netscape took a lot more to finish (Not +only Network traffic, also the specific HTTP-connection can be +significant sometimes). + +> the bug about http://www.hotmail.com seems to be a POST is improperly supported bug. +> I will have to set up a cgi and test it more thoroughly. + +Not the server expecting a cookie? (unsuported in dillo) + + +Jorge.- + + + +[Dillo-dev]I18n + +From: Sebastian Geerken - 2000-08-15 11:25 + +Hi! + +When dillo is supposed to be used by end users (in the future ;-), +perhaps we should start to internationalize it. Soon, because it gets +more difficult the more the project advances. From the view of a +programmer, gettext is quite simple to use (and can easily be +deactivated on systems on which it is not supported). + +I do not mean to start writing .po files, but simply prepare dillo by +using the "_" and "_N" macros, and define them as + +#define _(s) (s) +#define _N(s) (s) + +somewhere. Then, use of these macros should become part of the coding +standards. After this, the following tasks could be done later: + +- adding calls of setlocale() and textdomain(), and +- writing .po files. + +What do you think about this? + +Sebastian. + + + +[Dillo-dev]Html Parser + +From: Sebastian Geerken - 2000-08-15 10:42 + +Hi! + +Is there any reason for a separate function list F_list in html.c. Why +are the functions not directly integrated in the Tags list (static +TagInfo Tags[NTAGS])? + +Sebastian. + + + +[Dillo-dev]Dillo on StrongARM + +From: - 2000-08-15 10:34 + +Hi all, +I am glad to let you know that,dillo is port to StrongARM-110 and +StrongARM-11x0 board. +And I hope dillo will more strong!! + + +Best regards, + +Chester + + + +RE: [Dillo-dev]Misc. answers. + +From: Eric GAUDET - 2000-08-15 09:41 + +Le 15-Aug-2000, on m'a dit : +> > Anyway, we can get rid of the open +> > location window (because the location bar provides the same +> > functionality). +> > Comments? +> > +> +> please keep it. This allows me to "Ctrl-L, http://foo, enter" and +> never move +> my mouse. +> + +Alternatively, what do you think about getting rid of the location +window and Ctrl-L fucing the cursor to the location bar ? + +---------------------------------- +Eric GAUDET +Le 15-Aug-2000 a 18:39:05 +---------------------------------- + + + +RE: [Dillo-dev]Misc. answers. + +From: Sean 'Shaleh' Perry - 2000-08-15 08:47 + +> +> From the four patches you sent on the same thing, I finally +> kept the full entities list and used a libc binary search call. +> There're some interesting points: +> +> - All the isocodes in the list are not supported by current +> font (Some of them don't render). +> - Performance is a very relative subject here (commented below) +> +> (more on this subject near the bottom) +> + +My apologies on the rapid patches. I am used to people who want them early. +Plus I get eager (-: + +I hope I did not actually send you four identical files, I seem to recall each +adding onto the last. But yes, I could have held them and sent one big patch. + +In previous projects, smaller patches over time were easier to get applied than +one giant "I changed everything" patch. But each group is different. + +>> {Sean} +>> So, I used dillo some more today. yp.yahoo.com has a submit button whose +>> text +>> is: "Start Search". This is not handled by dillo either. So, I went +>> thru +>> and added Html_parse_entities() calls in a few more places. Now I need to +>> handle the memory use associated with this, right now I am leaking small +>> bits +>> of memory. Once I get this sorted out I will send a new patch. +> +> I found a better place that needs a single call to the entity +> parsing function. Not implemented yet, but if it works, I'll keep +> it. +> + +that would be cool, I have not quite understood all that is html.c + +>> {Sean} +>> The open location window does not seem to set itself as a transient. +>> This causes several window managers to hide the window when it opens. It +>> should load on top of the browser window. This window too could use some +>> beautification. +> +> Yes, that semms to be a bug. Anyway, we can get rid of the open +> location window (because the location bar provides the same +> functionality). +> Comments? +> + +please keep it. This allows me to "Ctrl-L, http://foo, enter" and never move +my mouse. + +>> loading large images is rather slow, I noticed this on screen +>> shot pages +> +> Mmmmm.... There's no special handling for image connections. +> Maybe you were downloading another document while fetching the +> page. This seems weird at the beginning, but it's possible! +> + +nope, simply going to some guys web page with a 1200x100 screen shot. + +>> {Sean} +>> Also, as I mention on #70, dillo acts like it does POST but doesn't. I am +>> reading the HTTP spec and looking at a proper implementation of this. If +>> anyone else is looking at this, let me know. +> +> I read your complaints on GET method too, the bug track engine +> uses GET and I've used POST without any problems. I'm not saying +> it's perfect, but can you be more specific please? +> + +the bug about http://www.hotmail.com seems to be a POST is improperly supported bug. +I will have to set up a cgi and test it more thoroughly. + +> +> Performance is a very relative subject here. Mainly because +> entities are scarce in the average HTML page (a minimal ratio), +> and because the Html_parse_entities function, returns without +> any searching almost all of the time (when the word doesn't have +> entities). +> + +absolutely, however, I do go to sites where there is an entity on every line. + + + +[Dillo-dev]Misc. answers. + +From: Jorge Arellano Cid - 2000-08-14 22:16 + +Hi everyone! +(I've been a bit overworked and also caught by a cold, I hope +that explains my disappearance ;) + + +Here I'll try to answer queued stuff: + +> {Sean} +> Bug #61: strrchr(parent, '/') returned NULL for . and .., but was assumed ok +> plus I added some more checking around the .dillo directory at startup. + +Integrated (done). + +> {Sean} +> Enclosed is a patch for #68. My solution was to pull the call to +> Html_parse_entities() out of the else, so it will get called regardless of the +> current DILLO_HTML_PARSE_MODE. Also, I changed the entities struct to include +> a len member and simply added the length of every entity to the array. +> ... by adding the len field the call to +> strlen() is removed from the for loop. This should help the performance of +> Html_parse_entities some. + +From the four patches you sent on the same thing, I finally +kept the full entities list and used a libc binary search call. +There're some interesting points: + +- All the isocodes in the list are not supported by current +font (Some of them don't render). +- Performance is a very relative subject here (commented below) + +(more on this subject near the bottom) + +> {Sean} +> So, I used dillo some more today. yp.yahoo.com has a submit button whose text +> is: "Start Search". This is not handled by dillo either. So, I went thru +> and added Html_parse_entities() calls in a few more places. Now I need to +> handle the memory use associated with this, right now I am leaking small bits +> of memory. Once I get this sorted out I will send a new patch. + +I found a better place that needs a single call to the entity +parsing function. Not implemented yet, but if it works, I'll keep +it. + +> {Sebastian} +> I encounterd a bug which sounds very simimar to #69: +> +> When I go to " +> and then, before the page is completely loaded (chances are quite good, +> since it is rather long), click on a link at the top, dillo starts to +> load and show the new page, but after a second or so *allways* crashes. + +Yes, I'll try to explain that here: + +That happens cause the IO engine is not finished yet. When you +load a page, and start loading another before the former +finishes, the IO emgine keeps loading and feeding both! (a sure +way for crashes). +That happens with the main page, not with images (unless the +image is the main page). +Images within an HTML page have already an aborting mechanism, +within the image sink, so the browser doesn't crash with these. + +A correct solution for this problem is not an easy task (I have +some ideas, but queued in favor of table support). + +> {Sean} +> Enclosed is a patch that includes the changes to html.c I sent last time along +> with the additional changes so that entities are checked for in FORM inputs +> as well. As far as I can tell, all entities are caught now. + +I hope the previous solution to work with forms too... + +> Also in my patch is a bug fix for Html_parse_entities(). If the html contained +> a malformed entity, i.e. "&", the output would be "mp". This would be a +> good item to add to test case html files. Another would be "&cpy;", which is +> copyright with a typo. This flexes the case where it is a valid form of an +> entity, but not a matching entity. + +In the spirit of XHTML, I don't aim to support "malformed" HTML +pages. Anyway, the bug fix is OK (I mean, unrecognized "entities" +must be rendered as a word). + + +> {Sean} +> The open location window does not seem to set itself as a transient. +> This causes several window managers to hide the window when it opens. It +> should load on top of the browser window. This window too could use some +> beautification. + +Yes, that semms to be a bug. Anyway, we can get rid of the open +location window (because the location bar provides the same +functionality). +Comments? + +> loading large images is rather slow, I noticed this on screen +> shot pages + +Mmmmm.... There's no special handling for image connections. +Maybe you were downloading another document while fetching the +page. This seems weird at the beginning, but it's possible! + +As you all may have noticed, dillo doesn't handle downloads +yet, but if you click on a link that has an unhandled MIME type, +the download starts, and is not aborted (see explanation above). +Furthermore, if you wait until it's got, you can put the url in +the location bar and force dillo to go there (nothing will be +rendered), and after that, hitting save does the trick! + +If not the case, I'm sure someone will appreciate the trick :) + +> The number of images gauge often shows "N of M" instead of "N of N", +> i.e. "20 of 23". Why are some images not getting loaded? + +Another subtle explanation! +Images are got in general, the problem is that the gauge is not +updated right (yes, a Bug). + +I say in general, because when the image hits a redirection, +it's not retrieved (not a bug, but lack of implementation). + +> {Sean} +> Also, as I mention on #70, dillo acts like it does POST but doesn't. I am +> reading the HTTP spec and looking at a proper implementation of this. If +> anyone else is looking at this, let me know. + +I read your complaints on GET method too, the bug track engine +uses GET and I've used POST without any problems. I'm not saying +it's perfect, but can you be more specific please? + +> {Sean} +> I re-did the core of Html_parse_entities(). The named entity check is now a +> binary search. Also added a few checks so that malformed html never makes it +> in to be checked. +> +> My initial tests show the new version is about twice as fast as the old one. +> [...] +> 76.92 0.10 0.10 6000 16666.67 16666.67 Html_parse_entities +> 15.38 0.12 0.02 main +> 7.69 0.13 0.01 6000 1666.67 1666.67 Html_parse_entities2 +> [...] +> Because a binary search is now used and I changed the code layout, the entity +> list no longer needs my previous addition of length values. This patch removes +> them. + +Performance is a very relative subject here. Mainly because +entities are scarce in the average HTML page (a minimal ratio), +and because the Html_parse_entities function, returns without +any searching almost all of the time (when the word doesn't have +entities). + +Anyway, testing with a page that has a "high entity ratio", +profiling shows that the time spent in Html_parse_entities is no +more that 5%, so optimizing the (5%xratio) is not very +significant. Even more, the older scheme used a linear search, +but its first items where the most expected entities, so it +usually performed better than the binary search. + +Please don't get me wrong, I was amazed too, so I pushed it +further and implemented a minimal perfect hash function for the +whole entities list. Guess what, the MPH function was slightly +faster than the binary search, but not worth the added complexity +though. The funny thing is that it was slower than the linear +search for pages that only used the top five entities of the +list! + +Knowing that since ISO-LATIN1 was adopted as the standar +charset for HTML (strongly decreasing the entities use), and +considering several other facts, I decided to trade off and used +a libc binary search and with the large entity list. + +---- + +Some final suggestions: + +- Please don't rush your patches to me. It's much better to +hold on for a while, test them thoroughly and finally sending +them. + +- Please don't post things you're not sure off without stating +clearly your doubts (Just to avoid confussion). + +- Please bear in mind that this is a public list and that +several persons read it. Think carefully what you post and +be as concise as you can. + + +I want to thank everyone that was kind enough to read this far, +and also want to thank the whole developing team for the +excellent work, and in particular, the polite bounds into which +we all agreed to express ourselves. + + +Sincerely +Jorge.- + + +Ps: I'm studying Sebastian's code and trying to find a way to +integrate the scroll-position remind feature into it. + + + +Re: [Dillo-dev]meta refresh support, and form POST + +From: Sean 'Shaleh' Perry - 2000-08-12 00:33 + +> +> Something like this might work: +> +> gboolean stuff_to_do(gpointer data) +> { +> Do the stuff that is to be done... +> +> return FALSE; +> } +> +> g_timeout_add(milliseconds, stuff_to_do, NULL); +> + +right, but the problem with a call back is I have to arrange for it to get data +somehow. Which would me some kind of global data )-: + +Will consider the possibilties though. + + + +Re: [Dillo-dev]some thoughts + +From: Sean 'Shaleh' Perry - 2000-08-12 00:32 + +On 11-Aug-2000 Sebastian Geerken wrote: +> Sean 'Shaleh' Perry wrote: +>> [...] +>> the view source window has the ok button at the bottom. It makes the +>> window +>> look ugly and is generally useless. +> +> What about starting an external text viewer, determined by the user? +> Dillo could write the content into a temporary file, or pipe it through +> stdin. The builtin text viewer could be left as standard, but should not +> be improved. +> + +nah, that is over kill. If the close button is removed, the window looks just +like netscape's -- just without syntax highlighting. + + + +Re: [Dillo-dev]meta refresh support, and form POST + +From: Jörgen Viksell - 2000-08-11 19:55 + +>Implementation question: the format is content="2;URL= +>where +>the '2' is the number of seconds before loading the page. How should I get +>this pause without freezing the browser? My current code ignores the +>delay completely. + +Something like this might work: + +gboolean stuff_to_do(gpointer data) +{ +Do the stuff that is to be done... + +return FALSE; +} + +g_timeout_add(milliseconds, stuff_to_do, NULL); + +// Jörgen + + + +________________________________________________________________________ +Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com + + + +Re: [Dillo-dev]some thoughts + +From: Sebastian Geerken - 2000-08-11 10:04 + +Sean 'Shaleh' Perry wrote: +> [...] +> the view source window has the ok button at the bottom. It makes the +> window +> look ugly and is generally useless. + +What about starting an external text viewer, determined by the user? +Dillo could write the content into a temporary file, or pipe it through +stdin. The builtin text viewer could be left as standard, but should not +be improved. + +Sebastian. + + + +[Dillo-dev]meta refresh support, and form POST + +From: Sean 'Shaleh' Perry - 2000-08-11 08:46 + +I am working on meta refresh support. This causes dillo to crash just like the +previously mentioned "click a link before the text is finished rendering" bug. +So, looks like I get to kill two birds with one stone (-: + +Implementation question: the format is content="2;URL= where +the '2' is the number of seconds before loading the page. How should I get +this pause without freezing the browser? My current code ignores the +delay completely. + +Also, as I mention on #70, dillo acts like it does POST but doesn't. I am +reading the HTTP spec and looking at a proper implementation of this. If +anyone else is looking at this, let me know. + +I have mailed Jorge several patches this week for improved entity support and +some minor speed improvements to html.c in general. + +See you all in a week (-: I will be reading mail sporadically. + + + +[Dillo-dev]some thoughts + +From: Sean 'Shaleh' Perry - 2000-08-10 23:56 + +Been using dillo off and on for most of this week. My list of little gripes so +far: + +the view source window has the ok button at the bottom. It makes the window +look ugly and is generally useless. + +The open location window does not seem to set itself as a transient. This +causes several window managers to hide the window when it opens. It should +load on top of the browser window. This window too could use some +beautification. + +loading large images is rather slow, I noticed this on screen shot pages + +the number of images gauge often shows "N of M" instead of "N of N", i.e. "20 +of 23". Why are some images not getting loaded? + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Jorge Arellano Cid - 2000-08-09 00:31 + +Sebastian, + +> > [...] +> > It should work in a reasonable way! +> > I mean, in a clear, unambiguous, and practical way. +> > (And finally we can always count on the always-reloading +> > scheme; dillo is very fast doing that). +> +> Yes, this is true. By testing I found that even long pages are reloaded +> in a reasonable time. +> +> Nevertheless, "not-reloading" is a nice feature, + +Of course it is. + +> but still not fully +> complete, and I will stop writing on it in the next time (meanwhile I am +> sucked of this whole problem :-). + +I've been there... + +> It will be deactivated it in the +> patch, but I think it should be left as an option for future extensions. +> +> Shall I remove and put it in a separate patch, or leave it in the code, +> but deactivate (#if 0 ... #endif) it? + +#if 0, it (I want to study the code anyway) + + +> PS: Is it possible to include .php pages or so into the html test suite? +> I used it to create some extreme situations, e. g. slowing down reading +> by including "". + +If that's to de done, I'd prefer it to have its own tarball. +Not everyone has a php-configured web server running. I like the +idea though. + + +Jorge.- + + + +RE: [Dillo-dev]Bug #69 + +From: Sean 'Shaleh' Perry - 2000-08-08 20:06 + +On 08-Aug-2000 Sebastian Geerken wrote: +> Hi! +> +> I encounterd a bug which sounds very simimar to #69: +> +> When I go to " +> and then, before the page is completely loaded (chances are quite good, +> since it is rather long), click on a link at the top, dillo starts to +> load and show the new page, but after a second or so *allways* crashes. +> + +I can confirm this. Most pages load so fast in dillo that this is hard to test +(-: But try this: + +go to a search engine page, search and as soon as a link appears click it. +Just keep clicking links as fast as they appear (who cares where they go). I +found about three or so in dillo dies. Most likely the result of lack of +function return value checking. + + + +[Dillo-dev]Bug #69 + +From: Sebastian Geerken - 2000-08-08 15:47 + +Hi! + +I encounterd a bug which sounds very simimar to #69: + +When I go to " +and then, before the page is completely loaded (chances are quite good, +since it is rather long), click on a link at the top, dillo starts to +load and show the new page, but after a second or so *allways* crashes. + +(You will get the wrong page because of bug #65, but after fixing the +bug, it remains the same.) + +If you wait, until the page has been loaded completely, all works. + +I hope this will helpful. + +Sebastian. + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Sebastian Geerken - 2000-08-08 12:58 + +Hi, Jorge! + +Jorge Arellano Cid wrote: +> > > Maybe, if the timeout function validates itself, the problem can +> > > be addressed in a simpler way. I mean, let the timeout function +> > > start, poll until it finds the #anchor, then set its AnchorFound +> > > flag and to continue correcting the value until: +> > > +> > > - #anchor is not found anymore or +> > > - user scrolls the page (either with keyboard or with mouse) +> > > When one of those happens, it removes itself. +> > +> > Changing of anchor positions depends of other things (e. g. images), so +> > this is not the point. +> +> I meant that it'd be clearer to let the timeout function remove +> itself, than to push a removal function into another function +> (an attempt to avoid coupling). + +Yes, this has been done from the beginning (except only two cases: +Dw_gtk_scroller_destroy, and before a new timeout function is started). + +> > An other point: A new behavior, which I have implemented, is, that the +> > page is *not* reloaded (even from cache) in some cases. Currently: if +> > old and new url are the same *and* there is no #anchor. In this case the +> > url is pushed, the scroller jumps to the anchor, but nothing is done +> > else. +> +> Interesting; careful considerations must be done though... +> +> > As I have seen, the HTML spec does not say anything about this, so how +> > should it work at the end? +> +> It should work in a reasonable way! +> I mean, in a clear, unambiguous, and practical way. +> (And finally we can always count on the always-reloading +> scheme; dillo is very fast doing that). + +Yes, this is true. By testing I found that even long pages are reloaded +in a reasonable time. + +Nevertheless, "not-reloading" is a nice feature, but still not fully +complete, and I will stop writing on it in the next time (meanwhile I am +sucked of this whole problem :-). It will be deactivated it in the +patch, but I think it should be left as an option for future extensions. + +Shall I remove and put it in a separate patch, or leave it in the code, +but deactivate (#if 0 ... #endif) it? + +Sebastian. + +PS: Is it possible to include .php pages or so into the html test suite? +I used it to create some extreme situations, e. g. slowing down reading +by including "". + + + +RE: [Dillo-dev]bug #68 + +From: Sean 'Shaleh' Perry - 2000-08-07 23:53 + +On 07-Aug-2000 Jorge Arellano Cid wrote: +> +> Sean, +> +> First of all, I want to welcome you to the project and to thank +> your first patch contributions (just integrated the first one; +> look at the bug-track). +> + +thanks, it is nice to have a free browser again (-: Hope to have all of #68 +done in the next few days. + +> +> Ps: Please don't send patches to the mailing list, send them +> directly to me (or privately upon request). +> + +will do. + + + +RE: [Dillo-dev]bug #68 + +From: Jorge Arellano Cid - 2000-08-07 23:19 + +Sean, + +First of all, I want to welcome you to the project and to thank +your first patch contributions (just integrated the first one; +look at the bug-track). + +> The functions without header comments (/* ? */), do we desire them to be +> commented? + +Yes! (It'd be great if we ever get the full source commented). + + +Jorge.- + +Ps: Please don't send patches to the mailing list, send them +directly to me (or privately upon request). + + + +Re: [Dillo-dev]Re: Plugins (was: Misc. answers) + +From: Jorge Arellano Cid - 2000-08-07 23:19 + +Eric, + +> What's good in using http rather than a raw html page? I'm afraid http would +> need much more code (libs) to do for a very small benefit (I can't even name +> one :-/). + +Take it easy, all you'll need to do is to output the HTML page +with a HTTP content header: + +························· +Content-Type: text/html + + +... + +························· + +You may also add a "Content-Length" field, but that's not a +requirement (this is exactly the same way we use to handle local +files). + +> ... or are we talking about the same thing ? ;-) + +Yes. +(No MIME, no libs, no complicated stuff, just a minimal HTTP +header). + + +Jorge.- + + + +RE: [Dillo-dev]bug #68 + +From: Sean 'Shaleh' Perry - 2000-08-06 23:45 + +On 06-Aug-2000 Sean 'Shaleh' Perry wrote: +> Enclosed is a patch for #68. My solution was to pull the call to +> Html_parse_entities() out of the else, so it will get called regardless of +> the current DILLO_HTML_PARSE_MODE. + +So, I used dillo some more today. yp.yahoo.com has a submit button whose text +is: "Start Search". This is not handled by dillo either. So, I went thru +and added Html_parse_entities() calls in a few more places. Now I need to +handle the memory use associated with this, right now I am leaking small bits +of memory. Once I get this sorted out I will send a new patch. + +The functions without header comments (/* ? */), do we desire them to be +commented? + + + +[Dillo-dev]Gif segfault : not dillo's bug + +From: Eric GAUDET - 2000-08-06 14:42 + +Hi all, +I've been testing dillo's image rendering for a while, and I noticed a segfault +with some gif (mostly banners, only animated ?). It's not dillo's fault, it's a +libungif fault (v4.1.0) : every imlib-dependant program segfaults. Version +4.1.0b1 corrects this bug, unfortunatly no package of this version is available +: you'll have to get the tarball from libungif site, compile and install it +yourself. Doing that, you'll break packages dependancies (imlib, ...), but +compilation and replacement is very easy. + +---------------------------------- +Eric GAUDET +Le 06-Aug-2000 a 23:35:52 +---------------------------------- + + + +[Dillo-dev]Re: est suite (was: Misc. answers) + +From: Eric GAUDET - 2000-08-06 10:27 + +Le 05-Aug-2000, on m'a dit : +> +> ---- [Test Suite] ---- +> +> > > The main point of it is to have a set of pages to test backward +> > > rendering capabilities (not breaking what was working in former +> > > versions of dillo), and to have a record of simple things that +> > > are not working yet, but that we're close to add. +> > > +> > +> > That would be a collection of existing pages you and other developers have +> > done before. (see above) +> +> And some other interesting stuff added later. +> +> > > Just assemble a small testing suite and you'll eventually +> > > receive contributions (I have some!). +> > +> > Do you want me to assemble the pages, then send you the assemblage for +> > publishing ? I can do that. +> +> Perfect. +> + +Ok, everybody send me your pages at the address below, in a tgz, if possible +with a short description of what each page is supposed to test. I'll put them +together. + +---------------------------------- +Eric GAUDET +Le 06-Aug-2000 a 11:56:07 +---------------------------------- + + + +[Dillo-dev]Re: Plugins (was: Misc. answers) + +From: Eric GAUDET - 2000-08-06 10:27 + +Le 05-Aug-2000, on m'a dit : +> ---- [Plugins] ---- +> +> > > The only difference is that information from the browser is +> > > passed to the plugin using its stdin, not the command line, and +> > > encoded as if the recepting program was a CGI. +> > +> > What do you mean with this CGI-thing : do you want the program to use HTTP +> > as transport, not stdout? +> +> The plugin-program outputs to its stdout in HTTP format. +> + +Herrr ... by http format, you mean a subset of it : some infos of the header +(content, cache). Not the full mime-encoding stuff, I hope. + +> > AFAIK CGIs prints to stdout for the web server. +> +> Right. +> + +an html page, plain text, no header, no http. The first bytes sent are " +Le 06-Aug-2000 a 12:07:10 +---------------------------------- + + + +[Dillo-dev]bug #68 + +From: Sean 'Shaleh' Perry - 2000-08-06 09:17 + +Attachments: dillo2.patch + +Enclosed is a patch for #68. My solution was to pull the call to +Html_parse_entities() out of the else, so it will get called regardless of the +current DILLO_HTML_PARSE_MODE. Also, I changed the entities struct to include +a len member and simply added the length of every entity to the array. +Since we know what the string is, it is silly to perform the computation. +This entire array could be dynamically generated from a list of entities, +assuming the list ever changes. By adding the len field the call to +strlen() is removed from the for loop. This should help the performance of +Html_parse_entities some. + +The two patches (this one and the last one) are independent of each other. + + + +[Dillo-dev]Bug #61 patch, plus extras + +From: Sean 'Shaleh' Perry - 2000-08-06 08:37 + +Attachments: dillo.patch + +It is soooo great to see a new browser. Anyway, here is a little contribution +to the cause: + +Bug #61: strrchr(parent, '/') returned NULL for . and .., but was assumed ok +plus I added some more checking around the .dillo directory at startup. + +To fully clean up #61, the path shown should not be: /path/to/directory/./. To +solve this I have to understand where the URL is getting sent from and where +the string displayed is shown. + +BTW, anyone have some emacs magic so I can edit the code with emacs? I used vi +for this so I could follow the coding standards. + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Jorge Arellano Cid - 2000-08-05 16:46 + +Sebastian, + +> Since I had problems to understand how several modules are connected, I +> tried to minimize communication between Html/Dw and GtkDwScroller by +> using flags and timeout functions. This is a workaround, but it will +> work ;-). I will comment and document my patch as good as it is needed +> by someone else, who wants to implement it more elegant, after he has +> understood the whole code better than I. + +Excellent, keep up the good work! + +> [...] +> What does not work correct: Go to a (large) page, scroll down and resize +> the window. Since the recalculation of the position is quite simple, you +> often get to a different position. But this has nothing to do with my +> patch. (A bug? Other browsers have this problem, too.) + +Yes, that's a different problem. +I think better to solve the #anchor problem well, before we +attempt to address this new one. +Remember that we still have to support remembering the +scrolling position of previously browsed pages (maybe just saving +the vertical adjustment value in the navigation stack). +[This problem will be affected by window resizes too.] + +> > Maybe, if the timeout function validates itself, the problem can +> > be addressed in a simpler way. I mean, let the timeout function +> > start, poll until it finds the #anchor, then set its AnchorFound +> > flag and to continue correcting the value until: +> > +> > - #anchor is not found anymore or +> > - user scrolls the page (either with keyboard or with mouse) +> > When one of those happens, it removes itself. +> +> Changing of anchor positions depends of other things (e. g. images), so +> this is not the point. + +I meant that it'd be clearer to let the timeout function remove +itself, than to push a removal function into another function +(an attempt to avoid coupling). + +> An other point: A new behavior, which I have implemented, is, that the +> page is *not* reloaded (even from cache) in some cases. Currently: if +> old and new url are the same *and* there is no #anchor. In this case the +> url is pushed, the scroller jumps to the anchor, but nothing is done +> else. + +Interesting; careful considerations must be done though... + +> As I have seen, the HTML spec does not say anything about this, so how +> should it work at the end? + +It should work in a reasonable way! +I mean, in a clear, unambiguous, and practical way. +(And finally we can always count on the always-reloading +scheme; dillo is very fast doing that). + + +Regards +Jorge.- + + + +[Dillo-dev]Re: Misc. answers + +From: Jorge Arellano Cid - 2000-08-05 16:46 + +Hi there! + +Here are some answers that were queued in my "todo:" list: + + +---- [Test Suite] ---- + +> > The main point of it is to have a set of pages to test backward +> > rendering capabilities (not breaking what was working in former +> > versions of dillo), and to have a record of simple things that +> > are not working yet, but that we're close to add. +> > +> +> That would be a collection of existing pages you and other developers have done +> before. (see above) + +And some other interesting stuff added later. + +> ... +> So, what you want basically is problem-exposing pages. + +Not only that. + +> > Just assemble a small testing suite and you'll eventually +> > receive contributions (I have some!). +> +> Do you want me to assemble the pages, then send you the assemblage for +> publishing ? I can do that. + +Perfect. + + +---- [PNG Code] ---- + +> > Finally, Geoff Lane (author of PNG support), told me it was +> > alpha code. +> > +> +> Does he still support the code, or is it up to us ? + +Geoff is not supporting it, so I guess it's up to Luca ;-) + +> I did all my testings with a png image _in_ an html page : if you don't have +> the bug when loading the page, you'll never have it when clicking reload. You +> have to quit dillo and reload the page. +> +> That strange : does dillo have a different caching behavior when the the +> "page" is an image? (it seems dillo re-decoding the image then) + +Good point! +Actually the caching scheme is only one, but cache querying is +different. When an IMG tag is found in a HTML page, the dicache +is asked for the image (decompressed image cache), and when it's +a bare URL, a_Cache_open_url is requested to do the job +(bypassing the dicache). + +The dicache code is expecting a full rewrite (I wrote that +before, but don't remember where nor to whom). + +Hope that helps. + + + +---- [Plugins] ---- + +> > The only difference is that information from the browser is +> > passed to the plugin using its stdin, not the command line, and +> > encoded as if the recepting program was a CGI. +> +> What do you mean with this CGI-thing : do you want the program to use HTTP as +> transport, not stdout? + +The plugin-program outputs to its stdout in HTTP format. + +> AFAIK CGIs prints to stdout for the web server. + +Right. + +> Will CGI environment variables be passed to the program ? (REMOTE_HOST and +> stuff) I don't see that useful. + +No, we'll forget about environment vars. + + +Jorge.- + + + +[Dillo-dev]New release! + +From: Jorge Arellano Cid - 2000-08-04 21:39 + +Hi there, + +A lot of work and effort has been put in this release. I hope +you all enjoy the difference. +Most notably there's new extensive documentation about dillo widget +(Dw), and IO.txt has been polished. + +I'll qoute a bit from IO.txt here: + +" Data transfer between threads inside the browser is handled by +pipes, shared memory is little used. This almost obviates the +need for explicit synchronization, which is one of the main areas +of complexity and bugs in concurrent programs. Dillo handles its +threads in a way that its developers can think of it as running +on a single thread of control. This is accomplished by making the +DNS engine call-backs happen within the main thread, and by +isolating file loading with pipes." + + + +Severals bugs and leaks were fixed, and stability also improved! + +Download and enjoy! + +Jorge.- +-- + + + +RE: [Dillo-dev]Re: Eric + +From: Eric GAUDET - 2000-08-02 04:50 + +Le 01-Aug-2000, on m'a dit : +> > then the program "bm" prints a html page in stdout (and can do something +> > else, like writing a file on the disk), which page dillo will render. +... +> +> Basically, that's the idea. +> +> The only difference is that information from the browser is +> passed to the plugin using its stdin, not the command line, and +> encoded as if the recepting program was a CGI. +> +> + +What do you mean with this CGI-thing : do you want the program to use HTTP as +transport, not stdout ? AFAIK CGIs prints to stdout for the web server. +Will CGI environment variables be passed to the program ? (REMOTE_HOST and +stuff) I don't see that useful. + +---------------------------------- +Eric GAUDET +Le 02-Aug-2000 a 13:41:55 +---------------------------------- + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Eric GAUDET - 2000-08-02 03:15 + +Le 01-Aug-2000, on m'a dit : +> Il mar, 01 ago 2000, hai scritto: +> +> > When I read libpng docs (example.c), it has directions on +> > decoding several images at the same time, so it seems that the +> > library can handle that. +> > On the other hand, I can't reproduce the bug with a single +> > image. +> +> I can. I open a png image then click on reload button several timesand I got +> a white image. +> + +I did all my testings with a png image _in_ an html page : if you don't have +the bug when loading the page, you'll never have it when clicking reload. You +have to quit dillo and reload the page. + +That's strange : does dillo have a different caching behavior when the the +"page" is an image ? (it seems dillo's re-decoding the image then) + +> > An interesting fact is that sometimes PNGs render not +> > completely white, but with colors bleached away! (One more hint +> > towards thinking the bug is PNG specific). +> +> Me too! +> + +I'll try again with image only. + +---------------------------------- +Eric GAUDET +Le 02-Aug-2000 a 12:08:52 +---------------------------------- + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Eric GAUDET - 2000-08-02 03:11 + +Le 01-Aug-2000, on m'a dit : +> +> Eric, +> +> > > Bug #4 (images as white square): I can reproduce it only with PNG. Gif +> > > and jpeg works just fine. Maybe a png specific problem ?!? +> > +> > I noticed the bug is much more frequent when there is several images: I +> > wonder if my libpng is compiled reentrant. +> +> When I read libpng docs (example.c), it has directions on +> decoding several images at the same time, so it seems that the +> library can handle that. +> On the other hand, I can't reproduce the bug with a single +> image. +> + +I've done all my testings using a page with a single png image. It happens. +It is true that it happens less with only one image (maybe 1 out of 20) than +with several images (my test page with 17 png has 2 to 5 white images each +time), but it happens. I noticed it happens less with the 17-images page when I +print a lot of debug informations during decoding, thus slowing down the +process, that's why I was thinking of a reentrance bug. I'm not sure now + +> An interesting fact is that sometimes PNGs render not +> completely white, but with colors bleached away! (One more hint +> towards thinking the bug is PNG specific). +> + +I'm using 64x32 one-color images, and sometimes (rarely) I have one or two +lines of randomly colored pixels. + +> Finally, Geoff Lane (author of PNG support), told me it was +> alpha code. +> + +Does he still support the code, or is it up to us ? + +---------------------------------- +Eric GAUDET +Le 01-Aug-2000 a 22:46:29 +---------------------------------- + + + +Re: [Dillo-dev]Html test suite + +From: Eric GAUDET - 2000-08-02 03:11 + +Le 01-Aug-2000, on m'a dit : +> +> The main point of it is to have a set of pages to test backward +> rendering capabilities (not breaking what was working in former +> versions of dillo), and to have a record of simple things that +> are not working yet, but that we're close to add. +> + +That would be a collection of existing pages you and other developers have done +before. (see above) + +> For instance, a page that reproduces the white square rendering +> bug, would be useful, + +I have a page doing that. Anybody interested ? + +> The other fact to take into account, is not to devote much time +> on assembling an HTML test suite, just find a page that shows +> some problems and add it to our test list; if you can reduce its +> size, that'd be good. +> + +So, what you want basically is problem-exposing pages. + +> Just assemble a small testing suite and you'll eventually +> receive contributions (I have some!). +> +> Ps: If you want my test examples, drop me a note. +> + +Do you want me to assemble the pages, then send you the assemblage for +publishing ? I can do that. + +I'll begin with "should-work-to-be-a-good-browser" pages : some basic text +formating and character rendering : everything dillo can do now (as for +v0.2.2), plus everything (I feel) should work on any decent browser. + +If anybody needs pages to test a specific problem and is not in the mood doing +doing them by himself, just send me an email I'prepare a few pages for the next +day. + +---------------------------------- +Eric GAUDET +Le 01-Aug-2000 a 23:32:24 +---------------------------------- + + + +RE: bookmarks [Dillo-dev]Re: Eric + +From: Eric GAUDET - 2000-08-02 03:11 + +Le 01-Aug-2000, on m'a dit : +> +> Eric, +> +> > You said that before and I love this idea. I'd like to see a practical +> > example of plugin, even alpha stage, before I decide I can do it right. +> +> OK, I'll try to provide you with that. +> (Most probably a patch over dillo-0.2.3). +> +... +> The only difference is that information from the browser is +> passed to the plugin using its stdin, not the command line, and +> encoded as if the recepting program was a CGI. +> + +Understood. I'm interested, then. + +---------------------------------- +Eric GAUDET +Le 01-Aug-2000 a 22:55:20 +---------------------------------- + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Luca Rota - 2000-08-01 23:14 + +Il mar, 01 ago 2000, hai scritto: + +> When I read libpng docs (example.c), it has directions on +> decoding several images at the same time, so it seems that the +> library can handle that. +> On the other hand, I can't reproduce the bug with a single +> image. + +I can. I open a png image then click on reload button several timesand I got a +white image. + +> An interesting fact is that sometimes PNGs render not +> completely white, but with colors bleached away! (One more hint +> towards thinking the bug is PNG specific). + +Me too! + +Ciao, +Luca + + + +Re: [Dillo-dev]Bug #10 (Anchors): questions + +From: Sebastian Geerken - 2000-08-01 15:08 + +Hi, Jorge! + +First a few notes: + +Anchors basicly work. There are a few details and tests to do, but I do +not think I will get severe problems. So the patch will propably be +finished in a few days. + +Since I had problems to understand how several modules are connected, I +tried to minimize communication between Html/Dw and GtkDwScroller by +using flags and timeout functions. This is a workaround, but it will +work ;-). I will comment and document my patch as good as it is needed +by someone else, who wants to implement it more elegant, after he has +understood the whole code better than I. + +Jorge Arellano Cid wrote: +> If the "scroller" and "view" code was right, maybe I'd suggest +> you to try a patch based on "changed" and "value changed" +> signals, but that code is a mess! + +I've tried to catch "changed" signals, but it didn't work reliable. The +timeout function works well, and is always removed at some point (there +is no "timeout function leak"). The only problem is, that it continues +running a while without use (and so taking a not measurable amount of +CPU time ;-), but this is only a question of design, not of runtime +behaviour. + +> [...] +> I see several things here: +> +> - The timeout function should not override user scrolling +> (i.e. if the user scrolls the page with the mouse). + +I already planned this. When, e. g, the user scrolls the page, before +the requested anchor has been read *anyway* (e. g. when transmission is +very slow, and meanwhile he is interrested in the informations at the +top of the page), he should not be confused by a sudden jump to an other +position (I think so). I have added a line to Dw_gtk_view_v_scroll, and +it works. + +> - Html_close can't be trusted to happen. + +Ok, I don't use it. (It does not work either in many cases.) + +> - Image reception can't be trusted. + +I didn't use it. + +> - It would be nice to have a #anchor display function that +> doesn't get fooled with page resizes (as we're trying). + +That works. Precisely, following works: + +1. Go to an url "foo#bar" where foo is very long and "#bar" at the very +bottom, then *immediately* resize the window (before the +is read). + +2. Go to a page, wait until it is loaded, resize the window, and jump to +an anchor in the same page. + +3. Go to an url "foo#bar", wait until it is visible (e. g. transmission +is over), and resize the window. (This is not really intended, but a +side effect, since the timeout function is still running.) + +What does not work correct: Go to a (large) page, scroll down and resize +the window. Since the recalculation of the position is quite simple, you +often get to a different position. But this has nothing to do with my +patch. (A bug? Other browsers have this problem, too.) + +> Maybe, if the timeout function validates itself, the problem can +> be addressed in a simpler way. I mean, let the timeout function +> start, poll until it finds the #anchor, then set its AnchorFound +> flag and to continue correcting the value until: +> +> - #anchor is not found anymore or + +Changing of anchor positions depends of other things (e. g. images), so +this is not the point. + +> - user scrolls the page (either with keyboard or with mouse) + +See above. + +> When one of those happens, it removes itself. + +An other point: A new behavior, which I have implemented, is, that the +page is *not* reloaded (even from cache) in some cases. Currently: if +old and new url are the same *and* there is no #anchor. In this case the +url is pushed, the scroller jumps to the anchor, but nothing is done +else. + +As I have seen, the HTML spec does not say anything about this, so how +should it work at the end? + +Sebastian. + + + +[Dillo-dev]Gtk containers + +From: Sebastian Geerken - 2000-08-01 15:08 + +Jorge Arellano Cid wrote: +[about docs] +> I think it's a matter cause it doesn't work as expected. Some +> parts are missing, some other are incomplete, and some have +> workaround tweaks. +> For instance, when Jörgen fixed the checkboxes, his code was +> right, but it didn't work because button widgets were not +> receiving the expose events. + +Perhaps a hint: The container implementations of GtkDwScroller and +GtkDwView look a bit incomplete. If you look e. g. at the source of +GtkBox, you find that there are 6 specific functions defined by +GtkContainer (like abstract virtual methods in C++), which are put into +the class structure: gtk_box_add, gtk_box_remove, gtk_box_forall, +gtk_box_child_type, gtk_box_set_child_arg and gtk_box_get_child_arg. So, +perhaps, Jörgen's code works, when GtkDwView is implemented in the +correct way. + + + +RE: [Dillo-dev]Bug #4, #62, #63 + +From: Jorge Arellano Cid - 2000-08-01 13:39 + +Eric, + +> > Bug #4 (images as white square): I can reproduce it only with PNG. Gif and +> > jpeg works just fine. Maybe a png specific problem ?!? +> +> I noticed the bug is much more frequent when there is several images: I wonder +> if my libpng is compiled reentrant. + +When I read libpng docs (example.c), it has directions on +decoding several images at the same time, so it seems that the +library can handle that. +On the other hand, I can't reproduce the bug with a single +image. + +An interesting fact is that sometimes PNGs render not +completely white, but with colors bleached away! (One more hint +towards thinking the bug is PNG specific). + +Finally, Geoff Lane (author of PNG support), told me it was +alpha code. + + +Jorge.- + + + +Re: [Dillo-dev]Bug #4, #62, #63 + +From: Jorge Arellano Cid - 2000-08-01 13:39 + +Seth, + +> > > Bug #63 (Segfault when you click enter in location field) +> +> I found that bug running on an older slack install, when I tried to reproduce +> it on a newer mandrake install everything seemed fine. + +Thanks for the explanation. + +Jorge.- + +Ps: Older than SLK-3.6? + + + +RE: [Dillo-dev]Re: Eric + +From: Jorge Arellano Cid - 2000-08-01 13:39 + +Eric, + +> > - Implementing the bookmarks as an external plugin. The idea of +> > doing it keeps rolling in my mind. Basically a dpi:/ (dillo +> > plugin) URL can be defined, and when accessing dpi:/bm (bookmark) +> > an external program can be launched on a thread to 'cat' the +> > bookmarks file (this is very much like current file handling). +> > The point with this scheme is that the plugin can be extended +> > to achieve more functionality (add, move, remove bookmark, make +> > category, etc). All implemented in a CGI fashioned way. +> > With that example, other people can start thinking of other +> > plugins, like a man page processor, or info file processor, a +> > dillorc options interface, etc. +> > +> +> You said that before and I love this idea. I'd like to see a practical example +> of plugin, even alpha stage, before I decide I can do it right. + +OK, I'll try to provide you with that. +(Most probably a patch over dillo-0.2.3). + +> What I understand, is there's a program called bm in ~/.dillo/plugin/ or +> /usr/local/lib/dillo/ (or is it /usr/local/share/dillo/ ?), that take its +> arguments on the command line (ie : when calling the URL +> "dpi:/bm?subdirectoy=News&fontsize=16", dillo is opening a read only pipe with +> the command line "bm subdirectory=News fontsize=16"), then the program "bm" +> prints a html page in stdout (and can do something else, like writing a file +> on the disk), which page dillo will render. +> Is that what you have in mind ? If not, can you describe precisely the calling +> mecanism, as well as the data retrieving. + +Basically, that's the idea. + +The only difference is that information from the browser is +passed to the plugin using its stdin, not the command line, and +encoded as if the recepting program was a CGI. + + +Jorge.- + + + +Re: [Dillo-dev]Bug #4, #62, #63 + +From: Jorge Arellano Cid - 2000-08-01 13:39 + +Luca, + +> Bug #4 (images as white square): I can reproduce it only with PNG. Gif and +> jpeg works just fine. Maybe a png specific problem ?!? + +Could be... +When I made the entry, a long time ago, it seemed to happen at +random images in ESR's page (not only PNGs there). But when I +checked it yesterday, the blank images were only PNGs. + +> Bug #62 (
tag's width problem): Dw_hruler_size_nego_y() (file dw_hrule.c) +> is commented. But that code seem ok! It works! Why is commented? + +Because I haven't finished it yet ;) +Dillo 0.2.3 will have it uncommented. + +> Bug #63 (Segfault when you click enter in location field): +> I can't reproduce it. + +After reading Seth's post, I decided to remove the entry. + + +Jorge.- + + + +Re: [Dillo-dev]Html test suite + +From: Jorge Arellano Cid - 2000-08-01 13:39 + +Eric, + +> I've done some pages to begin with : basic html structure, colors. I'm +> currently finishing the characters page. +> But I'm not sure what's urgent to do next. + +I understand. + +> What html specs do you want me to build test pages for (high and medium +> priority) ? Do you want first (only ?) well-formated documents, or do you need +> faulty documents too (missing, misplaced or incorrect tags) + +The main point of it is to have a set of pages to test backward +rendering capabilities (not breaking what was working in former +versions of dillo), and to have a record of simple things that +are not working yet, but that we're close to add. + +For instance, a page that reproduces the white square rendering +bug, would be useful, but a table rendering suit makes no sense +at this stage. + +The other fact to take into account, is not to devote much time +on assembling an HTML test suite, just find a page that shows +some problems and add it to our test list; if you can reduce its +size, that'd be good. + +Just assemble a small testing suite and you'll eventually +receive contributions (I have some!). + + +> PS: Do we aim for html 3 or html 4 compliance ? + +Neither one! +We strive for a "usable" HTML web browser. +(Kind of a vague answer, but true) + + + +Jorge.- + + +Ps: If you want my test examples, drop me a note. + + diff --git a/old/oldmail/200009.txt b/old/oldmail/200009.txt new file mode 100644 index 0000000..c12cd17 --- /dev/null +++ b/old/oldmail/200009.txt @@ -0,0 +1,2365 @@ +[Dillo-dev]Dillo weekly news + +From: Allan Clark - 2000-09-28 16:10 + +The first Dillo weekly news has been posted. +The url for those interested is +http://www.shark.pwp.blueyonder.co.uk/news240900.html + +Allan Clark +allan@al... +shark@bl... + + + +[Dillo-dev]Developer News + +From: Allan Clark - 2000-09-29 10:18 + +(Sorry if this is a repeat but I didn't get one back and there isn't one in +the archives.) +The first Dillo weekly news has been posted. +The url for those interested is +http://www.shark.pwp.blueyonder.co.uk/news240900.html + +Allan Clark +allan@al... +shark@bl... + + + +RE: [Dillo-dev]Repeated patch + +From: Allan Clark - 2000-09-24 14:46 + +Jorge, have you applied this patch? you're right the problem is deeper +routed, the fact is we shouldn't be getting the null pointer there, however +we should probably check for them just incase, so although this doesn't +solve the problem I think the patch should go in, alternatively in the mean +time use an assert there to assert that there is not a null pointer, this +way we know where it is failing and why and don't just get a crash. + +> -----Original Message----- +> From: dillo-dev-admin@li... +> [mailto:dillo-dev-admin@li...]On Behalf Of Jorge +> Arellano Cid +> Sent: 22 September 2000 19:19 +> To: dillo dev list +> Subject: Re: [Dillo-dev]Repeated patch +> +> +> +> Sam, +> +> > ... here's the patch I +> > sent again, as I never received a copy back (sorry if this is a repeat). +> +> Yes, the problem has very deep roots, and I'm still trying to +> find out a design solution that gets rid of all related problems. +> +> Whether to apply the "patch" is a matter of pragmatism. +> +> I'll keep trying to solve the problems behind... +> +> Jorge.- +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]Sorry + +From: Sam Dennis - 2000-09-24 01:43 + +Sorry if any of my last mails have got to you: they haven't got to me. + +Check the archives if they haven't, however. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Not again + +From: Sam Dennis - 2000-09-24 01:24 + +Getting tired of repeating. Check archives for messages. + + + +Re: [Dillo-dev]Missing mails again + +From: Sam Dennis - 2000-09-24 01:01 + +Argh! Why is it that only the important mails disappear? + +Well, they seem to be appearing on the archives, so if you're not receiving +them, best to check there. + +On the other hand, it could just be me. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Missing mails again + +From: Sam Dennis - 2000-09-24 00:50 + +I think it's done it to me again. Did anyone receive my reply to the comments +on the segfaults? + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Repeated patch + +From: Sam Dennis - 2000-09-24 00:08 + +On Fri, Sep 22, 2000 at 02:19:16PM -0400, Jorge Arellano Cid wrote: +> +> Sam, +> +> > ... here's the patch I +> > sent again, as I never received a copy back (sorry if this is a repeat). +> +> Yes, the problem has very deep roots, and I'm still trying to +> find out a design solution that gets rid of all related problems. +> +> Whether to apply the "patch" is a matter of pragmatism. +> +> I'll keep trying to solve the problems behind... + +Obviously I've been looking for the root causes, too. I get the impression +that this is some how to do with widgets that don't (or shouldn't) exist +receiving data from the caching system, but I'm probably completely wrong. + +As for applying the patch, I know that covering up the problem is generally +speaking a bad thing, but when it causes the program to crash extremely +frequently in normal usage unless the user is extremely cautious I think +that some soft of temporary measure is needed. Besides, there's another +problem that just occurs in images that I think is related, where the +structure that parent points to is filled with garbage, so the problem isn't +really covered up. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Dw (was new here) + +From: Sebastian Geerken - 2000-09-23 15:45 + +Hi Allan! + +I've still some doubts if the port is really a good thing, because: + +1. Gtk+ was designed for GUIs, but not for size negotiation e.g. +needed for tables. This could be solved by a Gtk+ widget set, see my +post to the list (subject "[Dillo-dev]Dw -> Gtk"). + +2. Gtk+ adopts the limitation of 32k pixels for an X window even for +windowless widgets, so you have a limited height for pages (when only +a part of DwPage is seen in a viewport), or at least for tables (when +the DwPage is itself the viewport). + +I've included my thoughts, which I sent Jorge, at the end of this +mail. + +Allan Clark wrote: +> [...] +> This all sounds great, if you need any help porting Dw just let me know what +> needs to be done. + +Send your ideas and comments on this topic. If you have an idea how to +solve the problem with the height limitation, without a new widget +set, that would be great. + +> I realised after I had sent the patch to the list that it was going to be a +> little obsolete as you were working on the port of Dw. I think the cvs +> version of the tree should be kept more up to date, I sent an e-mail to +> Jorge about that, below is part of that e-mail (which discussed a number of +> things) it is just an idea for dw_page which I think might help us with +> table and frame support, and you may be in a better position to decide. + +Currently, the ported DwPage is only on my local harddisk, according +to Jorge's philosophy of long holded patches, and since no one else +showed interest in it, before. If you are interested, I may send you +what I've done yet. + +Sebastian + +My mail to Jorge: + +I now think that is indeed not a good idea to use Gtk+ for the layout +of the html elements, but to continue using a much improved Dw. +Improvements coming currently to mind, are: + +- Include Dw into the Gtk+ object model, i.e. derive it from +GtkObject. So, Dw can use the strengths of Gtk+ objects. + +- Write a Gtk+ Widget GtkDwEmbed for embedding a Dw widget, replacing +GtkDwView, and probably best derived from GtkLayout. This widget must +first handle all embedded Gtk+ widgets (see below), and second wrap +the events for the Dw widgets. + +- Dw (or a derived class DwContainer) must strictly distinguish +between Dw widgets and Gtk+ widgets. E.g., the forall "method" of +GtkDwEmbed (defined by GtkContainer) should only work on the Gtk+ +widgets. Embedding Gtk+ widgets should be a mechanism of Dw itself, +not of DwEmbedGtk. + +An incomplete "class" hierarchy could look like this: + + +[GtkObject] +___________|_______________ +/ \ +Dw [GtkWidget] +__________|___________ | +/ | \ | +DwBullet DwImage DwContainer GtkDwEmbed +___|___ +/ \ +DwPage DwTable + + +Dw and DwContainer should be similar to GtkWidget and GtkContainer, +but with a few modifications, e.g. in size negotiation. An idea from +Gtk+, that containers are (partly) responsible for resising their +children, could also be adopted (see my post to the list). + + + +RE: [Dillo-dev]Dw (was new here) + +From: Eric GAUDET - 2000-09-23 05:08 + +-- En reponse de "RE: [Dillo-dev]Dw (was new here)" de Allan Clark, le +22-Sep-2000 : +> Lastly (bet you're glad) how far are we with tables/frames support, if the +> answer is "still discussing design options" then I would like to add my idea +> into the arena, I'm sure someone has probably suggested this, but, why don't +> we extend dw_page so that it can be one of the following +> 1)Contain a number of horizontal sub pages +> 2)Contain a number of vertical sub pages +> 3)Be a page as they are now, stored as lines. + +That should do it for frames, but tables are more complex than that : one can +colspan and rowspan a cell. Table implementation is difficult to be done with +the current line/word page structure. + +> Or we could have a wrapper, say dw_frame which could either contain +> horizontal subframes or vertical subframes or contain one dw_page, either +> way it is the same principle. + +Do we really need a whole dw_page for a frameset ? I don't think so. I think it +would be fairly easy to implement frames as a frameset (gtk) widget being mostly +a gtk containers tree, each containing a dw_page. + +> Also a page could be divided up for other things such as alignment, eg if +> you have two paragraphs the top is left aligned, and the bottom is center +> aligned, then we just divide it into two horizontal sub frames and all that +> would be needed would be coding to render a page whose lines are +> center/right alligned. + +This is intereseting. It looks like an extension of the current line/word page +construction. This probably can be done without the frame idea, though. + +----------------------------------- +Eric GAUDET +Le 23-Sep-2000 a 13:56:14 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Repeated patch + +From: Jorge Arellano Cid - 2000-09-22 20:09 + +Sam, + +> ... here's the patch I +> sent again, as I never received a copy back (sorry if this is a repeat). + +Yes, the problem has very deep roots, and I'm still trying to +find out a design solution that gets rid of all related problems. + +Whether to apply the "patch" is a matter of pragmatism. + +I'll keep trying to solve the problems behind... + +Jorge.- + + + +Re: [Dillo-dev]Plugins design + +From: Jorge Arellano Cid - 2000-09-22 20:09 + +Eric, + + +> Hi all, +> I'm currently working for plugins support in dillo, and I feel the need +> for a communication protocol between the plugin and dillo. + +Yes, but please try to make as much as possible with the +current scheme (bookmarks). + +I also see the need for a second plugin scheme, with +communication protocol, and better integration. The problem is +that currently we're trying to design the future widget scheme +and until that's done, the second scheme will have to wait. + +Jorge.- + + + +RE: [Dillo-dev]Dw (was new here) + +From: Allan Clark - 2000-09-22 19:39 + +Sebastian, + + + +> It is planned to port Dw to Gtk+, and I'm currently working on DwPage. +> DwHruler will then not used anymore (at least, unless all attributes +> will be supported), but simply GtkHSeparator. +> +> (I've some general doubts on the port, and wrote Jorge about it, but +> didn't get an anser yet.) +> +> I thought that size negotiation should be similar as in Gtk+, i.e. +> containers should (mainly) be responsible for it, plus a few +> extensions (look into the list archives). This is just your idea, +> except that all parameters are stored in the container. For this I +> defined: +> +> struct _DwPageChild +> { +> GtkWidget *widget; +> gfloat rel_width; /* 0: do not resize, +> otherwise: relative to DwPage's width */ +> gfloat rel_height; /* analogue */ +> }; +> +> /* ... */ +> +> void a_Dw_page_add_widget (DwPage *page, +> GtkWidget *widget, +> gfloat rel_width, +> gfloat rel_height, +> gint attr); +> +> Compare it e.g. with GtkBoxChild resp. gtk_box_pack_start. +> +> I tested it with GtkHSeparator (setting rel_width to 1.0), and it +> (mainly) works. This also makes rules with other widths simple (as +> soon as centered text is implemented). + + +This all sounds great, if you need any help porting Dw just let me know what +needs to be done. +I realised after I had sent the patch to the list that it was going to be a +little obsolete as you were working on the port of Dw. I think the cvs +version of the tree should be kept more up to date, I sent an e-mail to +Jorge about that, below is part of that e-mail (which discussed a number of +things) it is just an idea for dw_page which I think might help us with +table and frame support, and you may be in a better position to decide. + + +Next is the topic of the dillo widget, it says that on the dillo homepage +http://dillo.so....net/Notes.txt that the dillo widget needs a +revision, I gather from the list that Sebastian Geerken is porting the Dw to +plain GTK+ just like to say that this solution gets my vote, I don't see why +we should re-implement stuff that has already been done and tested and will +be further tested and updated for us. +Lastly (bet you're glad) how far are we with tables/frames support, if the +answer is "still discussing design options" then I would like to add my idea +into the arena, I'm sure someone has probably suggested this, but, why don't +we extend dw_page so that it can be one of the following +1)Contain a number of horizontal sub pages +2)Contain a number of vertical sub pages +3)Be a page as they are now, stored as lines. +Or we could have a wrapper, say dw_frame which could either contain +horizontal subframes or vertical subframes or contain one dw_page, either +way it is the same principle. +This as far as I can tell should be capable of coping with frames and +tables, even nested frames or tables, also it shouldn't be to difficult to +code the support for both tables and frames as frames are already divide a +page either horizontally or vertically, a table as well is just a divided +horizontally, with each horizontal division (ie a row) being divided up +vertically, so the html already lends itself to this kind of design. Also a +page could be divided up for other things such as alignment, eg if you have +two paragraphs the top is left aligned, and the bottom is center aligned, +then we just divide it into two horizontal sub frames and all that would be +needed would be coding to render a page whose lines are center/right +alligned. + + +Allan + + + +Re: [Dillo-dev]new here + +From: Sebastian Geerken - 2000-09-22 18:06 + +Allan Clark wrote: +> +> Hi +> As the subject says I'm new here, + +Welcome! + +> but I would like to submit a patch, +> which I *think* fixes bug number 62 where the horizontal rules mean that +> when Dillo reformats after being down-sized it gives the user an +> unneccesary horizontal slider. +> I defined a new flag in dw.c which is set when a widget is a set to fill +> all the horizontal space available, then dw_hruler.c is changed to set +> this flag and then dw_page.c is changed so that we check for the flag +> when reformating and deal with it accordingly. +> The way I have dealt with it means that the hrule will be as long as the +> text of the page is, this means that it won't be as long as an image +> which may be longer (check with dillo on the dillo homepage to see +> this), this is the way Netscape renders it, but would be easy to change +> if you don't like it. + +It is planned to port Dw to Gtk+, and I'm currently working on DwPage. +DwHruler will then not used anymore (at least, unless all attributes +will be supported), but simply GtkHSeparator. + +(I've some general doubts on the port, and wrote Jorge about it, but +didn't get an anser yet.) + +I thought that size negotiation should be similar as in Gtk+, i.e. +containers should (mainly) be responsible for it, plus a few +extensions (look into the list archives). This is just your idea, +except that all parameters are stored in the container. For this I +defined: + +struct _DwPageChild +{ +GtkWidget *widget; +gfloat rel_width; /* 0: do not resize, +otherwise: relative to DwPage's width */ +gfloat rel_height; /* analogue */ +}; + +/* ... */ + +void a_Dw_page_add_widget (DwPage *page, +GtkWidget *widget, +gfloat rel_width, +gfloat rel_height, +gint attr); + +Compare it e.g. with GtkBoxChild resp. gtk_box_pack_start. + +I tested it with GtkHSeparator (setting rel_width to 1.0), and it +(mainly) works. This also makes rules with other widths simple (as +soon as centered text is implemented). + +> Also I think it mucks up slightly if the horizontal rule is not directly +> after a hard break, (that is the hrule isn't on a line all by itself, again +> this should be easy to fix) it seems to render slightly further than it should. +> Anyway see what you think. + +Since
's are allways the only widget on a line, it is probably the +best to insert hard breaks before and after them. + +> [...] + +Sebastian + + + +Re: [Dillo-dev]email problems + +From: Eric GAUDET - 2000-09-22 03:59 + +-- En reponse de "Re: [Dillo-dev]email problems" de Jorge Arellano Cid, le +20-Sep-2000 : +> +> Eric, +> +>> Jorge, +>> I'm having the hardest time with my ISP loosing email for some domains. +>> Please +>> confirm you have received my patches. +> +> I haven't received a single one! +> + +Damn ! I haven't even got a non-delivery warning ! + +> (and I wrote to your address reporting that some time ago...) +> +> Shame I can't suggest you a good email provider. I switch +> between nettaxi and ematic :-). (Maybe you can try ematic as an +> alternative account). +> + +Actually, I tried 2 different smpt in 2 different countries with the same +(no-)result. +Do you mind if I try to send you some test emails to nettaxi and ematic ? + +Anyway, I posted all my patches and some explanations at : +http://www.rti-zone.org/dillo/ + +I'll try to fix these email problems soon. + +> Jorge.- +----------------------------------- +Eric GAUDET +Le 22-Sep-2000 a 12:39:40 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]email problems + +From: Jorge Arellano Cid - 2000-09-22 01:58 + +Eric, + +> Jorge, +> I'm having the hardest time with my ISP loosing email for some domains. Please +> confirm you have received my patches. + +I haven't received a single one! + +(and I wrote to your address reporting that some time ago...) + +Shame I can't suggest you a good email provider. I switch +between nettaxi and ematic :-). (Maybe you can try ematic as an +alternative account). + +Jorge.- + + + +[Dillo-dev]Repeated patch + +From: Sam Dennis - 2000-09-19 15:59 + +Attachments: html_loading.diff + +I think the mail server is eating my messages... anyway, here's the patch I +sent again, as I never received a copy back (sorry if this is a repeat). + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev](no subject) + +From: Allan Clark - 2000-09-19 13:16 + +Attachments: hrule2.diff + +Sorry about the empty e-mail I pressed the wrong button. +Here is the newer patch for the hrules which differ slightly from the original +and takes into account the feedback from Jorgen and Eric. + + + +[Dillo-dev](no subject) + +From: Allan Clark - 2000-09-19 13:11 + + + + + +RE: [Dillo-dev]horizontal rules + +From: Eric GAUDET - 2000-09-19 13:01 + +-- En reponse de "[Dillo-dev]horizontal rules" de Allan Clark, le 19-Sep-2000 : +> Quick question for you all. +> Should horizontal rules always be on a line by themeselves or should they be +> allowed to follow text. +> eg +> allan------ +> is that correct or should it be forced to be +> allan +> ----------- +> + +The latter is correct (html spec). +Stop worrying about hrulers, I sent a patch for HR full rendering and +correcting this behavior a few weeks ago (against 0.2.4, not published yet, but +likely due for next version) + +----------------------------------- +Eric GAUDET +Le 19-Sep-2000 a 21:54:46 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]horizontal rules + +From: Jörgen Viksell - 2000-09-19 12:54 + +>Quick question for you all. +>Should horizontal rules always be on a line by themeselves or should they +>be +>allowed to follow text. +>eg +>allan------ +>is that correct or should it be forced to be +>allan +>----------- + +The w3 recommendation defines it as a divider of sections of text. So I'd +say that it should be on its own line. + +// Jörgen + + +_________________________________________________________________________ +Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. + +Share information about yourself, create your own public profile at +http://profiles.msn.com. + + + +Re: [Dillo-dev]cache patch + +From: Luca Rota - 2000-09-19 12:32 + +Il sab, 16 set 2000, hai scritto: + +> actually. i have placed all released versions of dillo in cvs. Jorge is now +> using cvs. So cvs is newer than the release. + +Wow! Thank you, I didn't know. + +Ciao, +Luca + + + +[Dillo-dev]horizontal rules + +From: Allan Clark - 2000-09-19 11:37 + +Quick question for you all. +Should horizontal rules always be on a line by themeselves or should they be +allowed to follow text. +eg +allan------ +is that correct or should it be forced to be +allan +----------- + +Let me know what you think I can do it either way but I'm not sure which is +correct. +p.s. I realise the formatting of the above example might not work on some +e-mail clients but I kept it small so that it should on most. + +Allan Clark +allan@al... +shark@bl... + + + +[Dillo-dev]Test + +From: Sam Dennis - 2000-09-18 20:30 + +Just testing, haven't received any mails back from this thing, oddly. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Actual fix + +From: Sam Dennis - 2000-09-18 16:10 + +Attachments: html_loading.diff + +Sorry about the last patch, I didn't have a version of gdb that worked with +dillo so diagnosing the problem was difficult. It turns out that to fix bugs +#74 and #69, all that is needed is two simple checks. I'm sure that there's +a deeper problem, but it doesn't hurt to check for null pointers, which is +what we are currently getting, and this *does* solve the problem. + +Patch enclosed. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]new here + +From: Allan Clark - 2000-09-18 10:52 + +Attachments: hrule.diff + +Hi +As the subject says I'm new here, but I would like to submit a patch, +which I *think* fixes bug number 62 where the horizontal rules mean that +when Dillo reformats after being down-sized it gives the user an +unneccesary horizontal slider. +I defined a new flag in dw.c which is set when a widget is a set to fill +all the horizontal space available, then dw_hruler.c is changed to set +this flag and then dw_page.c is changed so that we check for the flag +when reformating and deal with it accordingly. +The way I have dealt with it means that the hrule will be as long as the +text of the page is, this means that it won't be as long as an image +which may be longer (check with dillo on the dillo homepage to see +this), this is the way Netscape renders it, but would be easy to change +if you don't like it. +Also I think it mucks up slightly if the horizontal rule is not directly +after a hard break, (that is the hrule isn't on a line all by itself, again +this should be easy to fix) it seems to render slightly further than it should. +Anyway see what you think. +I am also hoping that the new flag defined might help us in frames and tables, +where the frame or table cell width is not an absolute value but is given as +"whatever space is left after drawing the previous frames/table cells. +Also I don't think I have made the patch correctly, it says in the docs to use +diff -pru but when I did cvs came back with an error saying no such option, in +the end I used cvs diff > hrule.diff, please tell me if this is wrong and what +I should be doing. + +Allan + + + +[Dillo-dev]Debugging problems + +From: Sam Dennis - 2000-09-17 23:48 + +Has anyone else had problems debugging dillo with gdb? I'm getting unkown +signals soon after I run or attach. + +Admittedly, I am using a gdb release from '96... + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]cache patch + +From: Sean 'Shaleh' Perry - 2000-09-16 17:04 + +> Please, sends your patches to Jorge. But before takes the new dillo's version +> from download.so....net/dillo/ the cvs version is quite outdated. +> + +actually. i have placed all released versions of dillo in cvs. Jorge is now +using cvs. So cvs is newer than the release. + + + +Re: [Dillo-dev]cache patch + +From: Luca Rota - 2000-09-16 13:42 + +Il sab, 16 set 2000, hai scritto: + +Welcome, + +> Hi, I'm new to dillo development, although I worked with armadillo for a +> while, I've been looking at your cache system and have made a change which + +Oh, yes. I remember a justification patch and the html stack patch. Right? + +> seems to cause less segfaults when moving around without waiting for things +> to finish downloading (which has crashed dillo many times for me). It's +> probably not correct, but it does seem to improve the situation. + +Please, sends your patches to Jorge. But before takes the new dillo's version +from download.so....net/dillo/ the cvs version is quite outdated. + +Ciao, +Luca + + + +[Dillo-dev]cache patch + +From: Sam Dennis - 2000-09-16 04:15 + +Attachments: cache_patch.gz + +Hi, I'm new to dillo development, although I worked with armadillo for a +while, I've been looking at your cache system and have made a change which +seems to cause less segfaults when moving around without waiting for things +to finish downloading (which has crashed dillo many times for me). It's +probably not correct, but it does seem to improve the situation. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Sizes in html + +From: Sebastian Geerken - 2000-09-14 12:07 + +Hi! + +While porting the DwPage, I'm thinking about how widgets in the page +should be resized. (Anything except text will be a widget, even +probably
's with align=left/right (a new DwPage), but alignments +are far away from an implementation.) + +DwPage is derived from GtkContainer, and Gtk+ containers typically are +responsible on positioning and resizing of their children. (An +exception is, of course, when widgets resize thereselves, then the +container has to react on this.) E.g., if you want to add a widget to +a GtkBox, you use gtk_box_pack_start and set the arguments expand, +fill and padding to the appropriate values, and anything else is done +by the GtkBox. + +So, which parameters should be used by a_Dw_page_add_widget? My +current idea is based on relative width and height, or zero to prevent +resizing by DwPage. It the latter case, the widget's size has to be +set otherwise (e.g. by the html parser). This is quite obvious for +images, but it is also suitable for tables: they should (in most +cases) be added with a relative width of 100%, since they should be +resized when the page is resized, but then can calculate the size they +really need. + +Send any comments, about this idea in general, or if you find that my +idea is not suitable for a specified html elemtent. + +Another point is positioning. The only thing which comes currently to +mind, is the "align" attribute of some tags. But this will be done +later. + +Sebastian + + + +[Dillo-dev]email problems + +From: Eric GAUDET - 2000-09-13 06:27 + +Jorge, +I'm having the hardest time with my ISP loosing email for some domains. Please +confirm you have received my patches. + +----------------------------------- +Eric GAUDET +Le 13-Sep-2000 a 15:26:12 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Plugins design + +From: Sean 'Shaleh' Perry - 2000-09-13 00:30 + +> I have two options : +> - use a special Content-Type=x-dillo-command. What if we need to send +> both commands and a document in a single answer ? Either I'll have to +> dirty-hack the header parsing function to ignore and redirect +> x-dillo-command content until it finds an other content-type, or +> I'll have to add support for multipart-mime, which seems an overkill. +> - use special http header fields. Pragma seems to be an application +> specific sort-of field. Sending Pragma: AddMenu="Add Bookmark" would be +> understood by dillo to be a command sent by the plugin for him. +> Alternatively, we can use a non-http field (X-Dillo-Command:), as +> fields begining with X- can't exist in future http implementations, and +> it's a local communication anyway. +> + +If you must use http, you definately want to use X- headers. + + + +Re: [Dillo-dev]implementation question: how to decide if a font + +From: Sebastian Geerken - 2000-09-12 09:35 + +Sean 'Shaleh' Perry wrote: +> [...] +> > (Although the implementation looks a bit strange: 1. I think there +> > should be a global font list; 2. The Gdk fonts are not removed? But +> > this is a separate problem.) +> > +> +> yes, a global list would be nice, also, a global size array. I have font +> size=2 or font size=+3 working, but i had to implement a local size list +> because the open_h() function need a list in descending order and I wanted a +> list in ascending order. + +I think, it is not very important, where the fonts are stored, when +you have a simple interface to access them. This is an implementian +detail, which does not effect the code outside. + +BTW: Other widgets (e. g. buttons) use fonts, too. Currently, there +fonts are given by Gtk, but may the html author change them? + +> > I remember that there are a few more attributes (e.g. underlining, +> > backgrounds), which I will add perhaps, after my Gtk port of DwPage is +> > running correctly. +> > +> +> I am trying to implement the tag now. It looks like all I have to do is +> modify dw_page_expose_line(), this is where the link is underlined. However my +> boolean is not surviving into the function call. Most confusing. If I don't +> get it in a day or so, would you mind taking a peek? + +The best way will be to extend the DwPageAttr structure. Then any +attributes can be simply set by filling an DwPageAttr structure, and +DwPage will be responsible for render them. (I can do the last, but +first I want to finish the Gtk+ port to DwPage.) + +> > a_Dw_page_init_attr (DW_PAGE (page), &attr); +> > attr.font = a_Dw_page_find_font (DW_PAGE (page), &font); +> > attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr); +> > +> +> but a_Dw_page_find_font() does not actually check to see if a font can be +> rendered. What if your system lacked 'times new roman'. +> +> My text +> +> I have to decide which in that list of fonts I can use. In this case, Lucida +> and Helvetica are known to work, I am sure Arial will. But I have no way to +> query dillo to find out if font 'foo' can be loaded. +> +> Perhaps find_font should try to look up the font via gdk and give back a "could +> not find it" error? Or perhaps we need a query_system_font() to see if a font +> is valid, then find_font() to load it into dillo. + +The font is loaded in Dw_page_realize_font. Perhaps this function +could be modified, so that you may specify alternatives, when calling +a_Dw_page_find_font. As I wrote above, the interface should be as +simple as possible, so a query function is probably not a good idea. + +Sebastian + + + +[Dillo-dev]Plugins design + +From: Eric GAUDET - 2000-09-12 01:58 + +Hi all, +I'm currently working for plugins support in dillo, and I feel the need +for a communication protocol between the plugin and dillo. + +So far, dillo calls a plugin, sends a bunch of parameters, +and waits for an http-like answer, most of the time being +Content-Type=text/html ... + +Now, say the Bookmarks plugin wants to ask dillo to ask an "Add +Bookmark" menu, and also an "Edit Bookmarks" menu. How can it do that ? +Say the Ftp plugin wants to tell dillo he can handle "ftp://" urls, as +well as the "Mailto" plugin want to tell dillo he can handle "mailto:" +urls. How can it do that ? + +I have two options : +- use a special Content-Type=x-dillo-command. What if we need to send +both commands and a document in a single answer ? Either I'll have to +dirty-hack the header parsing function to ignore and redirect +x-dillo-command content until it finds an other content-type, or +I'll have to add support for multipart-mime, which seems an overkill. +- use special http header fields. Pragma seems to be an application +specific sort-of field. Sending Pragma: AddMenu="Add Bookmark" would be +understood by dillo to be a command sent by the plugin for him. +Alternatively, we can use a non-http field (X-Dillo-Command:), as +fields begining with X- can't exist in future http implementations, and +it's a local communication anyway. + +What do you think ? + +----------------------------------- +Eric GAUDET +Le 12-Sep-2000 a 10:38:04 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Misc. + +From: Eric GAUDET - 2000-09-12 01:36 + +--- En reponse de "Re: [Dillo-dev]Misc." de Luca Rota, le 11-Sep-2000 : +> Il dom, 10 set 2000, hai scritto: +> +> > If you'd like to know some of the reasons of current goals in +> > dillo, may I suggest: +> > +> > - Cathedral & the Bazaar (ESR) +> > - Homesteading the noosphere (ESR) +> > - http://www.levien.com/free/decommoditizing.html (Raph Levien) +> > - http://www.mcsr.olemiss.edu/~mudws/font.html +> > - http://www.tuxedo.org/~esr/html-hell.html +> +> May I suggest: +> http://www.levien.com/free/gzilla-tour.html (A tour of Gzilla 0.1.7) +> + +All these links deserve to be in dillo's home page. + +----------------------------------- +Eric GAUDET +Le 12-Sep-2000 a 10:35:42 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Misc. + +From: Luca Rota - 2000-09-11 16:55 + +Il dom, 10 set 2000, hai scritto: + +> If you'd like to know some of the reasons of current goals in +> dillo, may I suggest: +> +> - Cathedral & the Bazaar (ESR) +> - Homesteading the noosphere (ESR) +> - http://www.levien.com/free/decommoditizing.html (Raph Levien) +> - http://www.mcsr.olemiss.edu/~mudws/font.html +> - http://www.tuxedo.org/~esr/html-hell.html + +May I suggest: +http://www.levien.com/free/gzilla-tour.html (A tour of Gzilla 0.1.7) + +I'd like focus your attention on: +levien> the main design goals were that Gzilla be small, simple, and fast. I +had a few other goals. For one, I wanted Gzilla to be really good at +incremental rendering. + +levien> the Gzw (Gzilla Widget) framework was in place, providing a much more +powerful infrastructure for future development such as tables. + +Please, read the GZW section carefully. + +Note: Dillo is based on gzilla code and GZW is the original name of Dw. + +Ciao, +Luca + + + +Re: [Dillo-dev]Misc. + +From: - 2000-09-11 01:19 + +>From: "Jorge Arellano Cid" +>> Embbeding Perl 5... +> +> Although not a bad idea "per se", this is not the project for +>trying it. Dillo can't even render HTML by now, a module API is +>inexistent, and the Dw (dillo widget) is migrating to GTK+ in an +>effort to overcome a bunch of rendering-related problems. +> +> May I suggest galeon? It uses gecko, has an API, is smaller +>than mozilla and it's also free. + +Thanks for the pointer. I didn't see them on Freshmeat since they got +categorized under GNOME instead of with the other web browsers. + +I'll go look over there. Consider the patch that I sent for using glib +hash tables on the About menus to be a gift from an Open Source supporter +who was "passing through". (But I can understand if you'll want to +pull my personal URL out of there - I was planning on sticking around +when I put that there. :-) For future reference, that kind of patch +can also serve as an example of replacing linear searches with hash +lookups to build future scalability into your project. That's experience +I've gotten from 10 years working in the industry, including on OS's from +a mainframe Unix to an embedded OS for large routers. I hope it helps. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +Re: [Dillo-dev]implementation question: how to decide if a font + +From: Sean 'Shaleh' Perry - 2000-09-10 23:19 + +> +> a_Dw_page_init_attr (DW_PAGE (page), &attr); +> attr.font = a_Dw_page_find_font (DW_PAGE (page), &font); +> attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr); +> + +but a_Dw_page_find_font() does not actually check to see if a font can be +rendered. What if your system lacked 'times new roman'. + +My text + +I have to decide which in that list of fonts I can use. In this case, Lucida +and Helvetica are known to work, I am sure Arial will. But I have no way to +query dillo to find out if font 'foo' can be loaded. + +Perhaps find_font should try to look up the font via gdk and give back a "could +not find it" error? Or perhaps we need a query_system_font() to see if a font +is valid, then find_font() to load it into dillo. + + + +Re: [Dillo-dev]implementation question: how to decide if a font + +From: Sean 'Shaleh' Perry - 2000-09-10 23:04 + +> +> It's quite simple, but I think, you should only use the +> a_Dw_page_find_font function: Fill out a DwPageFont structure, then +> call this function, and you will get an index you can use in the +> DwPageAttr structure. I wrote something like the following, and it +> worked: +> +> +> +> Only as an example. You don't have to bother about loading and +> removing of fonts. +> +> (Although the implementation looks a bit strange: 1. I think there +> should be a global font list; 2. The Gdk fonts are not removed? But +> this is a separate problem.) +> + +yes, a global list would be nice, also, a global size array. I have font +size=2 or font size=+3 working, but i had to implement a local size list +because the open_h() function need a list in descending order and I wanted a +list in ascending order. + +> I remember that there are a few more attributes (e.g. underlining, +> backgrounds), which I will add perhaps, after my Gtk port of DwPage is +> running correctly. +> + +I am trying to implement the tag now. It looks like all I have to do is +modify dw_page_expose_line(), this is where the link is underlined. However my +boolean is not surviving into the function call. Most confusing. If I don't +get it in a day or so, would you mind taking a peek? + +> PS2: Two wishes: 1. Give the user the possibility to turn off any +> loading of non-standard fonts (except the user's style sheet), 2. A +> factor for size would be nice, i.e. the user should specify that dillo +> should use x times the font size specified by the author of the page. +> + +these are both great options. + +Once my font patch is accepted, I would also like a standard size list created +as mentioned above. I just winged it. + +Once I get underline working, I have all of the font modifying tags implemented. + + + +Re: [Dillo-dev]implementation question: how to decide if a font + +From: Sebastian Geerken - 2000-09-10 22:55 + +Sean 'Shaleh' Perry wrote: +> +> > +> > However, this is widely used. If you can do it easily, why not ? +> > +> +> it can be done fairly easily. style sheets also allow for aribitrary fonts to +> be used. +> +> My initial question was: how do we want to implement this? My experience with +> gtk is minimal, fonts even less. + +It's quite simple, but I think, you should only use the +a_Dw_page_find_font function: Fill out a DwPageFont structure, then +call this function, and you will get an index you can use in the +DwPageAttr structure. I wrote something like the following, and it +worked: + +DwPageFont font; +DwPageAttr attr; +gint attr_i; + +/* ... */ + +font.name = "times"; +font.size = 14; +font.bold = FALSE; +font.italic = FALSE; + +a_Dw_page_init_attr (DW_PAGE (page), &attr); +attr.font = a_Dw_page_find_font (DW_PAGE (page), &font); +attr_i = a_Dw_page_add_attr(DW_PAGE (page), &attr); + +a_Dw_page_add_text (DW_PAGE (page), "Some text.", attr_i); + +Only as an example. You don't have to bother about loading and +removing of fonts. + +(Although the implementation looks a bit strange: 1. I think there +should be a global font list; 2. The Gdk fonts are not removed? But +this is a separate problem.) + +I remember that there are a few more attributes (e.g. underlining, +backgrounds), which I will add perhaps, after my Gtk port of DwPage is +running correctly. + +Sebastian + +PS1: I'm currently porting DwPage to Gtk, but the interface will be +the same (except adding widgets), so I hope, your changes will run +with both versions of DwPage. + +PS2: Two wishes: 1. Give the user the possibility to turn off any +loading of non-standard fonts (except the user's style sheet), 2. A +factor for size would be nice, i.e. the user should specify that dillo +should use x times the font size specified by the author of the page. + + + +RE: [Dillo-dev]Misc. + +From: Sean 'Shaleh' Perry - 2000-09-10 22:22 + +> +> Gentleman, please, there's no CSS support in dillo by now, it's +> NOT a near future concern, and it can't cope with preferences +> like: +> +> "don't allow cookies" +> "download directory = ~/download" +> "discard animated gifs" +> "Don't load images" +> "Start with 600x400" +> etc... +> + +indeed, but it does handle: + +"no white backgrounds" +"use font "blah" for tag foo" +and just about any form of "I want html to look like" + +> -------------------------------------------------------------- +> +>> Badly written HTML... +> +> Well, certainly an arguable topic, but the current position is +> NOT to support badly written HTML. +> + +dillo should support the "oops" as much as possible. Simply forgetting to +close a tag should not ruin the rest of the page. Users will see this as a bug +in dillo. + +> - If the publisher wants to reach a broad spectrum, he'll +> strive for correct HTML. + +Web sites that allow users to post responses with embedded html have no means +to control what users enter. Letting a fellow open a font or bold tag and +making the rest of the page look horrid just seems wrong. It is trivial to get +tags like bold to clean up after previous bold tags. + +> -------------------------------------------------------------- +> +>> The question is do we want to actually make dillo display +>> html like the web author intended? +> +> Quite interesting question! +> +> The answer is: NO! +> +> Ideally, in dillo, the html should be displayed the way the +> user wants, not the author. +> + +back to CSS here. Load YOUR sheet last, and you override the author. + + + +[Dillo-dev]Misc. + +From: Jorge Arellano Cid - 2000-09-10 21:59 + +Hi! + + +Lots of email lately, hmmmm... + +Let's clarify some things: + +- Dillo is a lean, small and fast web client. +- Dillo still can't render HTML (This is the main goal) +- Dillo is very far away from supporting scripting languages. +- CSS is NOT a priority, nor a concern by now. +- Dillo aims to be a usable HTML web browser. + +The "fully standards compliant" browser project is mozilla, a +better start for scripting languages is galeon (uses the gecko +engine), if you also want to "get&feel" M$ content, you should go +with the latest flavour of IE (probably on Windoze!;), and if you +don't like Win* and also want the as-full-as-possible Internet +experience, you'd probably should keep with Netscape. + +If you'd like to know some of the reasons of current goals in +dillo, may I suggest: + +- Cathedral & the Bazaar (ESR) +- Homesteading the noosphere (ESR) +- http://www.levien.com/free/decommoditizing.html (Raph Levien) +- http://www.mcsr.olemiss.edu/~mudws/font.html +- http://www.tuxedo.org/~esr/html-hell.html + +-------------------------------------------------------------- + +> I have one problem that I can't seem to get around. Our site uses a SSL +> (security socket layer) that the standard http_proxy setting doesn't allow +> for. I would like some help regarding this issue if possible! + +Probably the easiest way around it is to grab the https pages +with 'curl' and sending them to dillo using dillo's simple plugin +scheme (currently in alpha, but working). +Sean's idea is also a good starting point (libssl). + +> Thanks again for making Dillo such a great product! + +Thanks to you for greeting us +(Would you believe that aprox. only 1 of 8 persons take time to +write a gentle comment at first post?) + +-------------------------------------------------------------- + +> Embbeding Perl 5... + +Although not a bad idea "per se", this is not the project for +trying it. Dillo can't even render HTML by now, a module API is +inexistent, and the Dw (dillo widget) is migrating to GTK+ in an +effort to overcome a bunch of rendering-related problems. + +May I suggest galeon? It uses gecko, has an API, is smaller +than mozilla and it's also free. + +-------------------------------------------------------------- +> ... +> as I mentioned in a previous mail, user preferences could easily +> be stored as a local style sheet which was added to the end of the style +> sheet reading. + +Gentleman, please, there's no CSS support in dillo by now, it's +NOT a near future concern, and it can't cope with preferences +like: + +"don't allow cookies" +"download directory = ~/download" +"discard animated gifs" +"Don't load images" +"Start with 600x400" +etc... + +-------------------------------------------------------------- + +> Badly written HTML... + +Well, certainly an arguable topic, but the current position is +NOT to support badly written HTML. + +Mainly due to: + +* http://www.levien.com/free/decommoditizing.html +- If the publisher wants to reach a broad spectrum, he'll +strive for correct HTML. + +Note: I'm sure there're different opinions on this. + +-------------------------------------------------------------- + +> The question is do we want to actually make dillo display +> html like the web author intended? + +Quite interesting question! + +The answer is: NO! + +Ideally, in dillo, the html should be displayed the way the +user wants, not the author. + +One of the things a dislike more about Netscape is to have to +see the page's as the author wants. No matter how hard I try to +set my preferences to use certain fonts and sizes, they seem to +always find the trick to get over my settings. +Not to mention scaled fonts that look trembling & tiny, etc. + +Finally, I definitively agree that those pages have, by far, a +better looking result when looked from a distance :-). Personally +I do prefer dillo's rendering for reading HTML documentation. + +-------------------------------------------------------------- + +Jorge.- + + + +RE: [Dillo-dev]implementation question: how to decide if a font + +From: Sean 'Shaleh' Perry - 2000-09-10 19:46 + +> +> However, this is widely used. If you can do it easily, why not ? +> + +it can be done fairly easily. style sheets also allow for aribitrary fonts to +be used. + +My initial question was: how do we want to implement this? My experience with +gtk is minimal, fonts even less. + + + +RE: [Dillo-dev]implementation question: how to decide if a font + +From: Eric GAUDET - 2000-09-10 09:38 + +--- En reponse de "RE: [Dillo-dev]implementation question: how to +decide if a font" de Sean 'Shaleh' Perry, le 10-Sep-2000 : +> > +> > A good thing would be to load 2 fonts (proportionnal and mono) from +> > dillorc and use only these everywhere in dillo. +> > I'm not sure you want to load fonts on request. You probably can do +> > it, +> > it's even possible other browsers do it, but I'm not sure it's +> > needed. +> > +> +> dillo currently uses: courier and lucida for special tags and +> helvetica for everything else. The question is do we want to +> actually make dillo display html like the web author intended? I +> can understand not wanting to load each and every font asked for, +> but requests for items like arial or in the case of +> freshmeat lucida, which we are already using, why not allow it? + +The html author is not supposed to ask for a font (even if he can) : +only if it's proportionnal or fixed width. He's not even supposed to +specify B(old), I(talic) or any style, but use instead STRONG, EM tags. +That's the same thing of using special chars instead of entities. + +However, this is widely used. If you can do it easily, why not ? + +----------------------------------- +Eric GAUDET +Le 10-Sep-2000 a 18:32:45 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]implementation question: how to decide if a font + +From: Sean 'Shaleh' Perry - 2000-09-10 06:56 + +> +> A good thing would be to load 2 fonts (proportionnal and mono) from +> dillorc and use only these everywhere in dillo. +> I'm not sure you want to load fonts on request. You probably can do it, +> it's even possible other browsers do it, but I'm not sure it's needed. +> + +dillo currently uses: courier and lucida for special tags and helvetica for +everything else. The question is do we want to actually make dillo display +html like the web author intended? I can understand not wanting to load each +and every font asked for, but requests for items like arial or in the case of +freshmeat lucida, which we are already using, why not allow it? + + + +RE: [Dillo-dev]implementation question: how to decide if a font + +From: Eric GAUDET - 2000-09-10 06:46 + +--- En reponse de "[Dillo-dev]implementation question: how to decide if +a font is v" de Sean 'Shaleh' Perry, le 10-Sep-2000 : +> I am working on . There is no central list of +> fonts dillo +> is willing to support or a way to query them. Html_page_check +> declares an array +> of 4 font names, but only helvetica ([0]) is used from that array. +> + +teletype style and PRE use courier, but hard-coded, not from this array +(which is local anyway). + +... +> +> can dillo load font 'foo'? +> +> Suggestions? I suspect this will require code in dw_page.c. +> + +A good thing would be to load 2 fonts (proportionnal and mono) from +dillorc and use only these everywhere in dillo. +I'm not sure you want to load fonts on request. You probably can do it, +it's even possible other browsers do it, but I'm not sure it's needed. + +----------------------------------- +Eric GAUDET +Le 10-Sep-2000 a 15:34:09 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]implementation question: how to decide if a font is valid + +From: Sean 'Shaleh' Perry - 2000-09-10 06:00 + +I am working on . There is no central list of fonts dillo +is willing to support or a way to query them. Html_page_check declares an array +of 4 font names, but only helvetica ([0]) is used from that array. + +the face attribute of font is a comma separated list of the fonts the html +author wanted to use, in order of preference. To continue with freshmeat: + + + +so, try Lucida, then Verdana, then Helvetica, then settle for Arial. + +What I need is a way to say: + +can dillo load font 'foo'? + +Suggestions? I suspect this will require code in dw_page.c. + + + +[Dillo-dev]handling poorly written html + +From: Sean 'Shaleh' Perry - 2000-09-10 05:45 + +So, was reading the recent freshmeat editorial when i noticed that freshmeat's +html creation software likes to leave 's open. So I tried to make bold +close any open bold tags. First I tried Html_cleanup_tag(), which was already +in use and thus documented. However cleanup_tag only handles the case of +"

", i.e. back to back tags. freshmeat was doing "". +So I looked at pop_tag. This function appears to properly handle the case +where there are extra tags between the tag in question and the one I want +removed. my dillo can now read html that has dangling b tags. Will probably +add more of this type code as we discover other bad html. + +Point of this letter is this: Html_cleanup_tag is redundant considering the +power of Html_pop_tag. Html_cleanup_tag also fails miserably on many pieces of +html. I have a patch prepared which removes this function and replaces all +calls to it with Html_pop_tag. + +Comments? + +P.S. Html_pop_tag has a todo comment, handle the case where tags dont nest. As +I have stated above, it seems to do so. Can anyone point to cases where it +fails? + + + +RE: [Dillo-dev]on the subject of SCRIPT tags + +From: Sean 'Shaleh' Perry - 2000-09-10 02:41 + +> +> I guess the events (onClick in a A tag,...) are to be done yet. +> + +yep, setup the events and then make it so they call the interpeter. + + + +RE: [Dillo-dev]News + +From: Sean 'Shaleh' Perry - 2000-09-10 02:40 + +> +> I remember that. Do we support style sheets now ? (or are we about to ?) +> Good idea anyway. +> + +no, but it is on my todo list. As I mentioned we can inch our way in by +storing prefs in style sheet format. This gets the style sheet parser working. + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: - 2000-09-10 02:27 + +>From: Eric GAUDET +>Embeding perl in dillo would probably never go into dillo's main +>distribution. But that doesn't mean it's not interesting nor you +>shouldn't do it. Find your way doing it as a side project for dillo +>using dillo's standard interfaces (plugin or module). + +Well, it's too big an effort to undertake unless it's likely the +project will embrace it to a greater degree than that. + +I fully respect that the volunteers who have contributed to the project +should determine its direction. And I think Dillo looks promising. + +But I'm sure it won't be a surprise if I continue looking for a place +where the browser-side perl idea would have a stronger acceptance. I'm +willing to do this work but I most certainly don't want it to disturb +volunteers who have already contributed. Maybe the idea's time just +hasn't come yet. + +In any case, I appreciate the time you've taken to help me consider what +the options were for this idea. I wish you success. I'll mention this +project to anyone who sounds like they might be interested in volunteering. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +RE: [Dillo-dev]News + +From: Eric GAUDET - 2000-09-10 02:14 + +--- En reponse de "RE: [Dillo-dev]News" de Sean 'Shaleh' Perry, le +09-Sep-2000 : +> > +> > I'm working on the Bookmarks plugin right now, and I've got lots of +> > ideas fo plugins things. I'm willing to make a Preferences plugin +> > too, as I saw the project is suspended and drake is most likely +> > out of dillo. +> > +> +> as I mentioned in a previous mail, user preferences could easily be +> stored as a local style sheet which was added to the end of the +> style sheet reading. This way user prefers override the author's +> prefs. Or maybe an option "override web author?". If no, the +> style would be read first. +> +> style sheets let the user specifiy almost anything about the look of +> a web page +> -- bg color, image, text colors by tag, etc. +> +> If you could make the preference item output a style sheet formatted +> file, we can only load it and ignore style sheets for right now. + +I remember that. Do we support style sheets now ? (or are we about to ?) +Good idea anyway. + +----------------------------------- +Eric GAUDET +Le 10-Sep-2000 a 11:12:05 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: - 2000-09-10 02:14 + +>From: "Sean 'Shaleh' Perry" +>And here I was thinking the point of dillo was not to be the next mozilla. +> +>Guys, just once could a project do its job and only its job. I want a lean, +>mean, web browser. It should support whatever the w3c says a web browser +>should support and that is about it. Maybe some little tweaks to make a user's +>life happier. + +OK, I understand. + +That was why I asked. I didn't know the opinions out there. You're all +the ones who have done the work so far and that must be respected in +any volunteer effort. The polite thing to do was bring it up for +discussion and actually listen to the answers. + +Well, I'm listening and it's 0 for 2 right now. One more makes it +a trend. :-) Oh well. It was worth the try. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: Eric GAUDET - 2000-09-10 02:11 + +--- En reponse de "Re: [Dillo-dev]idea: embed Perl5 in Dillo" de Ian +Kluft, le 09-Sep-2000 : + +> Those examples were looking further out in the future, assuming this +> feature were accepted by the group and had time to build out +> access to lots of Dillo's APIs. I'm thinking of starting with a +> module, adding perl interfaces to existing Dillo module APIs one +> at a time, and seeing where it goes from +> there. The idea of a plugin could be explored as a follow-on. +> + + +Ok, as you seem quite excited by this idea, here are your options: + +- If you don't feel the need for constant interaction with dillo, go +for a plugin. You can do that without any dillo-dev consensus : this is +an external program (a project outside of dillo) launched in a shell by +dillo when clicking on a fake url "dpi:///", +doing his job (such as saving a file), sending datas to dillo (such as +an html page), then exit. Plugins are being implemented now (I did a +plugin-lib and I'm studying dillo's side calls), you'll be able to test +your plugin quite soon, and you'll have support (by me at least ;-) + +- If you can live without dillo's interactions, you'll need a module. +There's no module interface planned for now : you'll have to design it, +and it will be accepted only if it's a generic module interface (not +perl-specific) so others can benefit your work and do other modules. +You'll have to work alone because we don't want to bloat dillo with a +bunch of modules, and we don't feel immediate use of modules (you've +heard Sean : I believe he doesn't want modules at all, I'm not sure I +want that myself). + +Embeding perl in dillo would probably never go into dillo's main +distribution. But that doesn't mean it's not interesting nor you +shouldn't do it. Find your way doing it as a side project for dillo +using dillo's standard interfaces (plugin or module). + +ciao + +----------------------------------- +Eric GAUDET +Le 10-Sep-2000 a 10:45:10 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]on the subject of SCRIPT tags + +From: Eric GAUDET - 2000-09-10 01:19 + +--- En reponse de "[Dillo-dev]on the subject of SCRIPT tags" de Sean +'Shaleh' Perry, le 09-Sep-2000 : +> One of the patches I have given Jorge is to have script tags use the +> stash. +> So, now all of the script code is stored somewhere, you just have to +> get +> it to the interpreter and add support for script hooks in html tags. + +I guess the events (onClick in a A tag,...) are to be done yet. + +----------------------------------- +Eric GAUDET +Le 10-Sep-2000 a 10:17:46 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]News + +From: Sean 'Shaleh' Perry - 2000-09-09 19:12 + +> +> I'm working on the Bookmarks plugin right now, and I've got lots of +> ideas fo plugins things. I'm willing to make a Preferences plugin too, +> as I saw the project is suspended and drake is most likely out of dillo. +> + +as I mentioned in a previous mail, user preferences could easily be stored as a +local style sheet which was added to the end of the style sheet reading. This +way user prefers override the author's prefs. Or maybe an option "override web +author?". If no, the style would be read first. + +style sheets let the user specifiy almost anything about the look of a web page +-- bg color, image, text colors by tag, etc. + +If you could make the preference item output a style sheet formatted file, we +can only load it and ignore style sheets for right now. + + + +[Dillo-dev]on the subject of SCRIPT tags + +From: Sean 'Shaleh' Perry - 2000-09-09 19:08 + +One of the patches I have given Jorge is to have script tags use the stash. +So, now all of the script code is stored somewhere, you just have to get +it to the interpreter and add support for script hooks in html tags. + + + +RE: [Dillo-dev]idea: embed Perl5 in Dillo + +From: Sean 'Shaleh' Perry - 2000-09-09 19:07 + +And here I was thinking the point of dillo was not to be the next mozilla. + +Guys, just once could a project do its job and only its job. I want a lean, +mean, web browser. It should support whatever the w3c says a web browser +should support and that is about it. Maybe some little tweaks to make a user's +life happier. + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: - 2000-09-09 18:49 + +>From: Eric GAUDET +>I'm not really against the idea : I know perl, I like perl, I don't +>know javascript. If you think you can achieve that fast and _as_a_ +>_dillo_module_, good for you and for us. (I don't see immediate +>applications, though, but if you do it, I'll most likely use it ;-) + +OK, thank for that note. :-) + +Yes, as I re-read the docs for the difference between a module and a plug-in, +I think a module is what I had in mind. The intent behind it could also +be thought of as a way to write new Dillo modules in perl. + +It's something that I've thought since the dawn of the web that someone +should do with a browser. Nearly all my web software development over +that time has been on the server side. Over the years, work on several +closed-source web servers has occasionally prevented me from contributing +to projects like Apache. Although I did take one opportunity to contribute +a module (mod_mime_magic) that Apache accepted in 1997. + +In the meantime, perl never happened on the browser side. So I'm looking +around for a project which would be receptive to the idea. Dillo is the +first choice after a quick survey because it uses GTK with no Motif legacy, +it's GPL, it's relatively new, etc. Admittedly, I'm in no political +position to push this on any project so this idea completely depends on +others liking it too. If I can't convince anyone, the idea goes nowhere. + +>But we need to keep dillo's priorities in mind : dillo's still lacking +>a lot of important features for a browser, and we sure can use some +>extra coders. (If you know gtk+ and you want to help with tables and +>frames support, contact Jorge) + +Sorry - I've been on the server side of the web. I don't have that +kind of experience. + +I can understand that the project needs to have priorities. Even if this +idea doesn't (yet) serve a higher priority, I'll accept the repsonsibility +to make sure it doesn't get in the way of them. I think after some of the +implementation is started, it could actually help implement some of the +priorities. + +>Having an embeded language would be nice, but IMHO the criterias for +>such a thing in dillo are : +>- either a quick-hack, very lightweight, non-standard language (ie: not +>javascript) : no wasting our time doing that, just add some dillo-only +>dynamic html pages. +>- or javascript, with all the efforts it needs. +> +>My main concern is : why perl ? If you spend a lot of time glueing perl +>with dillo, I'd prefer you do it in a way other languages can be +>interfaced too. I know you link about embeding perl in a C program, but +>it's too much perl-specific to my taste. + +Well, yeah, it's still in the thinking/proposal stage. But the idea looks +like the perl-specific code would have to be kept to its own separate module. +On the surface of it, except for occasional additional functions in some +API's to make information available to other modules (like the perl module), +I don't yet see any reason why it can't be contained in its own module +much like mod_perl contains all the perl-specific code in Apache. + +As I continue to form the idea with your input, this Dillo module would +be glue code between the Dillo APIs and Perl APIs. Each would view the +other as a module, and access to their APIs. + +>> The thought I had for Dillo was not to replace any existing C code +>> in Perl. But rather it should allow access to as many as possible +>> of the APIs so that some new features can be prototyped or +>> implemented as an embedded perl script calling Dillo API functions. +>> It could also customize things like menus by putting embedded +>> perl scripts behind some of the callbacks that handle them. +>> (Imagine having live Slashdot headlines in a pulldown menu. :-) +> +>This has been discussed in this list a few weeks ago (check the +>archives), under the name of "modules", and rejected (for now) because +>it seemed too much work and second priority. + +OK, sorry. Then that wasn't a good example. :-) Time to go through +the archives... (So far I've gone through the web site and been watching +the mail list for a couple weeks.) + +But the point is that such extensions could be possible to write in perl, +not just in C. + +>Some of your examples let me think you might want to implement a perl +>"plugin", which is not a "module", much more like a local CGI (check +>the archives for that too, or ask me, as I'm the one working on +>plugins). I like _this_ idea : you could put together and maintain your +>perl plugin without bothering patching/linking with dillo, because it +>would be an _external_ program called by dillo. + +Those examples were looking further out in the future, assuming this feature +were accepted by the group and had time to build out access to lots of +Dillo's APIs. I'm thinking of starting with a module, adding perl interfaces +to existing Dillo module APIs one at a time, and seeing where it goes from +there. The idea of a plugin could be explored as a follow-on. + +>Anyway, embeding whatever in dillo will be Jorge's decision eventually: +>wait for his answer before you begin something big ;-) + +:-) Yup, don't worry. I did read the authors page. I haven't written +any code for this yet. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: Eric GAUDET - 2000-09-09 13:37 + +--- En reponse de "Re: [Dillo-dev]idea: embed Perl5 in Dillo" de Ian +Kluft, le 09-Sep-2000 : +> The main question is whether people want it. I clearly understand +> your first impression was against the idea, and respect your +> opinion. If you're still open for some more technical info, take +> a look at +... + +I'm not really against the idea : I know perl, I like perl, I don't +know javascript. If you think you can achieve that fast and _as_a_ +_dillo_module_, good for you and for us. (I don't see immediate +applications, though, but if you do it, I'll most likely use it ;-) +But we need to keep dillo's priorities in mind : dillo's still lacking +a lot of important features for a browser, and we sure can use some +extra coders. (If you know gtk+ and you want to help with tables and +frames support, contact Jorge) +Having an embeded language would be nice, but IMHO the criterias for +such a thing in dillo are : +- either a quick-hack, very lightweight, non-standard language (ie: not +javascript) : no wasting our time doing that, just add some dillo-only +dynamic html pages. +- or javascript, with all the efforts it needs. + +My main concern is : why perl ? If you spend a lot of time glueing perl +with dillo, I'd prefer you do it in a way other languages can be +interfaced too. I know you link about embeding perl in a C program, but +it's too much perl-specific to my taste. + +> The thought I had for Dillo was not to replace any existing C code +> in Perl. But rather it should allow access to as many as possible +> of the APIs so that some new features can be prototyped or +> implemented as an embedded perl script calling Dillo API functions. +> It could also customize things like menus by putting embedded +> perl scripts behind some of the callbacks that handle them. +> (Imagine having live Slashdot headlines in a pulldown menu. :-) + +This has been discussed in this list a few weeks ago (check the +archives), under the name of "modules", and rejected (for now) because +it seemed too much work and second priority. + +Some of your examples let me think you might want to implement a perl +"plugin", which is not a "module", much more like a local CGI (check +the archives for that too, or ask me, as I'm the one working on +plugins). I like _this_ idea : you could put together and maintain your +perl plugin without bothering patching/linking with dillo, because it +would be an _external_ program called by dillo. + +Anyway, embeding whatever in dillo will be Jorge's decision eventually: +wait for his answer before you begin something big ;-) + +----------------------------------- +Eric GAUDET +Le 09-Sep-2000 a 22:04:07 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]idea: embed Perl5 in Dillo + +From: - 2000-09-09 12:42 + +>From: Eric GAUDET +>"Embeding" perl can be done in two ways : you can merge perl in dillo, +>or link to perl dynamically. +>IMHO, the fist is not doable : perl is too much heavy and I think we +>want to keep dillo's light weight. + +I'm sure it's doable. But I'd have to implement it one API function +at a time. It can also be done so that it's optional and you could +leave it out at compile time. + +The main question is whether people want it. I clearly understand your +first impression was against the idea, and respect your opinion. If you're +still open for some more technical info, take a look at +http://www.cpan.org/doc/manual/html/pod/perlembed.html +http://www.cpan.org/doc/manual/html/pod/perlguts.html +That's how a Perl5 interpreter can be embedded into any C program, or +vice versa. A number of performance-critical Perl modules have been +reimplemented in C too. + +So the embedding can go both ways. The perl interpreter can be a shared +library. Or it can accept any module as a shared library. + +The counterpart to this idea on the server side is mod_perl for Apache. +Perl and Apache each think the other is a module. :-) The perl interpreter +runs inside the Apache process. I've used mod_perl on the job or on +my personal web servers almost as long as it's been out. + +The thought I had for Dillo was not to replace any existing C code in Perl. +But rather it should allow access to as many as possible of the APIs so +that some new features can be prototyped or implemented as an embedded perl +script calling Dillo API functions. It could also customize things like +menus by putting embedded perl scripts behind some of the callbacks that +handle them. (Imagine having live Slashdot headlines in a pulldown menu. :-) + +Also, depending on what access there might be to control the display +window, it could be possible to have some kinds of local forms and pages +controllable within the browser, and feed responses directly into +browser-side perl code instead of a remote web server. So it could be a +kind of scriptable local GUI in addition to a remote web browser. But it +would take a lot of incremental API support before enough internal APIs +could be covered to allow that. + +If the consensus is not to do this on Dillo, I can look around for another +browser to try this on. But I like Dillo so far and think it has good +potential. So I'm still holding out hope that some others will like +the idea. + +>The latter seems better, adding support for the SCRIPT tag (a script in +>an html page can actually be in any language, albeit javascript is the +>only one used). But that's a lot of work : adding event calls on each +>widget (links, images, words, almost all javascript's Document calls), +>then figure out an interface between perl and dillo. +>Though perl is quite an interesting language, my advice would be to +>support javascript first (there's 2 open sourced javascript engines +>around), because this will be immediatly usefull. Then you can add perl +>with the same scripting interface. +> +>A few days ago, I tried to evaluate how hard it would be to embed a +>tiny scripting language in dillo (10KB max), dillo-specific, so I can +>add dynamic behavior to my dillo-plugins-generated pages. I suspended +>this project for now, but if you dillo guys think that can be an +>interesting add-on, tell me. +> +>Ian, if you want to add SCRIPT tag to dillo, I can help. + +Well, the SCRIPT tag will be needed for future Javascript support anyway. +No doubt about that. + +But I'd be hesitant to allow it to use Perl. There is a Perl5 SAFE module +which is intended to act as a kind of sandbox. But it doesn't have wide +enough testing or trust to confidently use as downloadable code in a +browser. I can almost see the CERT advisories already... + +Besides, there's no support among current web sites or browsers for such +functionality right now. + +Though you would probably still have needed to use the perlembed interface +to link a perl interpreter in for the SCRIPT tag. So I don't think it +would have turned out any better on your concerns of a larger program size. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +RE: [Dillo-dev]idea: embed Perl5 in Dillo + +From: Eric GAUDET - 2000-09-09 11:35 + +"Embeding" perl can be done in two ways : you can merge perl in dillo, +or link to perl dynamically. +IMHO, the fist is not doable : perl is too much heavy and I think we +want to keep dillo's light weight. +The latter seems better, adding support for the SCRIPT tag (a script in +an html page can actually be in any language, albeit javascript is the +only one used). But that's a lot of work : adding event calls on each +widget (links, images, words, almost all javascript's Document calls), +then figure out an interface between perl and dillo. +Though perl is quite an interesting language, my advice would be to +support javascript first (there's 2 open sourced javascript engines +around), because this will be immediatly usefull. Then you can add perl +with the same scripting interface. + +A few days ago, I tried to evaluate how hard it would be to embed a +tiny scripting language in dillo (10KB max), dillo-specific, so I can +add dynamic behavior to my dillo-plugins-generated pages. I suspended +this project for now, but if you dillo guys think that can be an +interesting add-on, tell me. + +Ian, if you want to add SCRIPT tag to dillo, I can help. + +--- En reponse de "[Dillo-dev]idea: embed Perl5 in Dillo" de Ian Kluft, +le 09-Sep-2000 : +> Part of my intent behind the just-submitted about-URL-hashing +> experiment was +> to dig around the sources to check what it might take to embed Perl5 +> in +> Dillo. I envision this as an optional feature, not a requirement, +> since +> it would fit Dillo's goal of extensibility very well but would also +> add +> to its size. Such compromises should be weighed by group +> discussion. +> (I haven't been on the list long enough to know the Dillo developer +> community well.) +> +> I've wanted for a long time to try to embed Perl in a web browser. +> The +> possibilities for local user interface control seem very powerful. +> But it +> would be better to work on such changes with a relatively new +> browser where +> the concept can grow with the project if it's accepted by other +> participants. +> I'll watch the following discussion for everyone's opinions... +> -- +> Ian Kluft KO6YQ PP-ASEL sbay.org +> coordinator +> ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San +> Jose, CA +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +----------------------------------- +Eric GAUDET +Le 09-Sep-2000 a 20:17:40 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]idea: embed Perl5 in Dillo + +From: - 2000-09-09 11:03 + +Part of my intent behind the just-submitted about-URL-hashing experiment was +to dig around the sources to check what it might take to embed Perl5 in +Dillo. I envision this as an optional feature, not a requirement, since +it would fit Dillo's goal of extensibility very well but would also add +to its size. Such compromises should be weighed by group discussion. +(I haven't been on the list long enough to know the Dillo developer +community well.) + +I've wanted for a long time to try to embed Perl in a web browser. The +possibilities for local user interface control seem very powerful. But it +would be better to work on such changes with a relatively new browser where +the concept can grow with the project if it's accepted by other participants. +I'll watch the following discussion for everyone's opinions... +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +[Dillo-dev]patch: add hashing to "about:" handler + +From: - 2000-09-09 11:00 + +Attachments: dillo-about-patch + +Hello. This is a simple patch while I'm learning my way around Dillo. +It changes the "about:" URL handler to use a hash table. It also adds an +a_About_add() function so other parts of Dillo can dynamically add their +own about-string/URL pairs on the fly. + +Though I submit to the editorial authority of the project coordinators, +I used the patch to show how this can more easily and scalably add +about-URLs for developer resources (like the Dillo, gtk and glib home pages) +or for project participants to add their own URLs (with two of mine shown +as an example.) Hopefully that will be viewed as a "perk" for contributing +source code and add to the popularity of the project. + +The patch is submitted to the project as an attachment to this message. +Or if you want to give me permission to commit it myself, my SourceForge +user name is ikluft. +-- +Ian Kluft KO6YQ PP-ASEL sbay.org coordinator +ikluft(at)thunder.sbay.org http://www.kluft.com/~ikluft/ San Jose, CA + + + +[Dillo-dev]seen this a couple of times + +From: Sean 'Shaleh' Perry - 2000-09-09 10:03 + +***** BUG found! (buffer needs allocation) ***** +Width = 1, Height = 1 + +I can not reproduce it. + + + +[Dillo-dev]word of caution and my status + +From: Sean 'Shaleh' Perry - 2000-09-09 09:35 + +I have initial working of the FONT tag functional. I can say Hi there and get blue text. Will code the rest. + +The warning is that html_push_tag has to be called as early in a function as +possible. I was having problems with open_font() because I was calling +html_push_tag() at the end and thus pushing myself too far onto the stack it +seems. the close font tag would not reset the text color. simply moving the +function call fixed it. + + + +RE: [Dillo-dev]Great Product! + +From: Sean 'Shaleh' Perry - 2000-09-09 03:29 + +> +> I have one problem that I can't seem to get around. Our site uses a SSL +> (security socket layer) that the standard http_proxy setting doesn't allow +> for. I would like some help regarding this issue if possible! +> + +dillo could use ssl support -- feel free to help us code it. Or find someone +else to contribute the code to us. + +start with libssl. + + + +[Dillo-dev]Great Product! + +From: Bill Brooks - 2000-09-09 02:52 + +To all concerned! + +Dillo is a great tool! I am working on a project that involves kiosk web +browsing on thin clients with Linux RH61. We need to keep the operation +simple and lock the user down to a limited range of use. Dillo seems to be +the best browser that I have come across. It is simple (if browsers can be +termed simple), fast, and can be extensible with knowledge of C and gtk+ +programming. + +I have one problem that I can't seem to get around. Our site uses a SSL +(security socket layer) that the standard http_proxy setting doesn't allow +for. I would like some help regarding this issue if possible! + +Thanks again for making Dillo such a great product! +Bill Brooks +MIS Anaylst +Lowe's Companies, Inc. + + + +RE: [Dillo-dev]News + +From: Eric GAUDET - 2000-09-08 19:00 + +06-Sep-2000, Jorge said : +> Personally, I gave a look to reload and double-click bugs, and +> noted that they're most the same problem. +... +> As a matter of fact, I'm currently working on it. +... + +Shouldn't you register in the bug tracking database accordingly ? + +Anyway, I had email sending problems lately, and I was wondering if +you've received my patches. + +I'm working on the Bookmarks plugin right now, and I've got lots of +ideas fo plugins things. I'm willing to make a Preferences plugin too, +as I saw the project is suspended and drake is most likely out of dillo. + +----------------------------------- +Eric GAUDET +Le 08-Sep-2000 a 22:25:38 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]News + +From: Jorge Arellano Cid - 2000-09-06 13:58 + +Hi! + +The list has been quiet for some time, and that's a good sign! +(we are diligently working on the code by now). + +Personally, I gave a look to reload and double-click bugs, and +noted that they're most the same problem. There're also a several +more problems related to this that are not recorded in the +bug-track. The main problem is the lack of implementation of a +consistent error control and abort systems between different +layers in dillo. This is a design concern. + +I also noted that it deserves a high priority on my list, +because new developers don't know the internals of the browser +and perceive dillo as crash-prone, and get discouraged, instead +of knowing that this is just a lack of implementation that's to +be overcomed soon. + +As a matter of fact, I'm currently working on it. + +I checked and fixed the cache clients scheme to handle not only +concurrent clients on the same connection, but also to provide a +handler for error control and aborting (This means that +concurrent download functionality is working). + +As a mentioned above, the problem is among middle layers. For +instance: do you remember Sebastian's post about image +backgrounds? Yes, current scheme handles image transfers directly +to rendering image widgets. I'm also working on that. + +Note that this is not a patching task, but a design one, that +takes time and key decisions have to be made, so I'll take some +time in trying to get it right. + + +Jorge.- + + +PS: I wander if some among the new memebers are experienced GTK+ +developers... + diff --git a/old/oldmail/200010.txt b/old/oldmail/200010.txt new file mode 100644 index 0000000..57816c2 --- /dev/null +++ b/old/oldmail/200010.txt @@ -0,0 +1,3767 @@ +[Dillo-dev]Dw details + +From: Sebastian Geerken - 2000-10-31 15:04 + +Hi! + +Some details on my Dw design. Implementation is far enough to make be +beleive that this design should work quite well. In detail: + +- DwWidget: set_width and set_height are currently not used, instead, +this feature is currently implemented otherwise. Will be changed +next. +The implementation of a_widget_queue_resize is currently very simple +and inefficient, but works; changes should not effect the other +code. + +- DwContainer: There won't be much implementation, anyway. + +- Interaction between Gtk and Dw: GtkLayout does a good job ;-). +Embedding of Gtk+ widgets by DwEmbedGtk works mainly. (BTW, focus +works very nice now.) + +DwWidget +-------- + +My goal for the new design was mainly to make dillo's widgets more +similar to Gtk+ widgets. + +struct _DwWidget +{ +GtkObject object; + +/* some more members, will change */ +}; + + +struct _DwWidgetClass +{ +GtkObjectClass parent_class; + +void (*size_request) (DwWidget *widget, +DwRequisition *requisition); +void (*size_allocate) (DwWidget *widget, +DwAllocation *allocation); +void (*set_width) (DwWidget *widget, +guint32 width); +void (*set_height) (DwWidget *widget, +guint32 height); +void (*draw) (DwWidget *widget, +DwRectangle *area, +GdkEventExpose *); +/* further methods for events */ +}; + +size_request and size_allocate work quite exactly as in GtkWidget. I +added two methods, set_width and set_height, which may (but need not) +have an effect on the behaviour of size_request. (Probably, set_height +will not be used anyway, but it is there for symmetry.) Most widgets +in dillo will use size_request much more often that size_allocate. + +There is a function a_dw_widget_queue_resize, which a widget must call +when its desired change has changed (e.g. if a word is added to a +page). The implementation is based on the size_request and +size_allocate methods, similar to gtk_widget_queue_resize), so a +widget must not implement anything like idle functions etc. (BTW, +a_dw_widget_queue_resize as well as gtk_widget_queue_resize do work +with idle functions.) + +Since DwWidget's are windowless "per se", there is no need for +distinguishing between a draw and an expose method. However, if the +draw function is called because of an expose event, the method will +receive it as third argument (otherwise NULL), in case, if the widget +is interested in further details. + + +DwContainer +----------- + +Quite similar to GtkContainer. + + +Interaction between Gtk and Dw +------------------------------ + +The top level Dw widget is handled by a Gtk+ widget GtkDwViewport, +derived from GtkLayout. GtkDwViewport is responsible for all events +for Dw widgets, the underlying GtkLayout for events for embedded Gtk+ +widgets. + +There is still a widget DwEmbedGtk for embedding Gtk+ widgets into a +DwWidget. Some "events" (like destroy or size_request) of those +widgets have to be caught by signals, since Gtk+ does not regard the +DwEmbedGtk as the parent of the Gtk+ widget. + +(I first tried another approach, without GtkLayout, which made the +design simpler, but had severe problems with the Gtk+ widgets. So I +decided to use GtkLayout, which does a good job for this.) + + +Sebastian + + + +RE: [Dillo-dev]Progress + +From: Sean 'Shaleh' Perry - 2000-10-30 00:36 + +During some recent plane trips I have mostly finished my work on dillo and +rendering of font modifying tags. font tab itself is supported, it does not +yet support the face attribute. The sub and super tags need attention, they +are the only major things not working yet. + +I intend to add a flag to dillo's configuration to ignore all font modifying +tags in the html, or only specific ones. I have even pondered saying it is ok +if font color= is set, but not font face=. Jorge, I know how much you hate not +being able to control what html authors do and I would like to give our users a +rich set of control over this. Personally, I like to see pages the way the +author intended, but I know not everyone does. Comments on implementation of +user prefs welcome. Need just a little cleanup of the code and I can submit a +patch. + +Jorge, would you like for this to happen after Sebastian's Dw changes? + +Sorry for not being very talkative lately, this is the first time this machine +has been on in a week. + + + +[Dillo-dev]Dw progress + +From: Sebastian Geerken - 2000-10-28 10:43 + +Hi! + +Another good news: Dw is working quite nice already. Embedding Gtk+ +widgets is now (nearly) perfect, there are no expose problems anymore, +even resize queueing of Gtk+ widgets are recognized. After making +some changes and fixing some bugs, I'll soon start re-intigreating it +into dillo. + +A note to bug #86: tabbing between widgets works automatically (done +by the base class GtkLayout or somewhere else), but the toplevel Gtk+ +widget (GtkDwViewport) isn't focussable yet, so e.g. the arrow keys +don't work. Making GtkDwViewport focussable will cause some other +problems, since you may not focus children of focussable containers by +pressing the tab key (but you may by clicking on them). I'll work on +it (and make an entry in the bug tracking engine). + +Images: I'll first deactivate images, and then take a look at Jorge's +changes. + +Sebastian + + + +[Dillo-dev]Dillo-plugins first release + +From: Eric GAUDET - 2000-10-27 16:07 + +Hi guys, +As I promised, I just made available all the Dillo-plugins stuff I've +been working on at: +http://www.rti-zone.org/dillo/ + +Feel free to send me any comments about this. +It's stable and almost complete, so you can try and do your own +Dillo-plugins right now. + +I'm still working on the patch, and I'll finish it hopefully soon +enough to be reviewed by Jorge and integrated in Dillo v0.3. + +A usable Bookmarks Dillo-plugin will be available soon too, but its +developement will be disconnected of Dillo. (I'm not forking Dillo ! +The purpose of plugins is to be external programs). +The internal bookmarks menu won't be removed until Jorge decides so. + +Ciao + +----------------------------------- +Eric GAUDET +Le 28-Oct-2000 a 00:55:24 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Progress + +From: Jorge Arellano Cid - 2000-10-27 12:40 + +Hi! + +A few days ago I finally devised a way to simplify the complex +alternative design; it was a major task with lots of changes that +I hope to document in the future. + +The good news is that I have a running prototype of dillo-0.3.0 +with it! + +The prototype runs very good and only requires some polishing +before being adopted as the basis for our new release. + +In brief: + +- The imgsink stuff was completely removed. +- The dicache was rewritten from scratch and integrated +into the normal cache. +- A single client queue is being used for both caches. +- The file descriptors were replaced by cache keys that serve +as connection handlers. +- The image data structure and related sources got changed. +- Every decoder (png, gif, jpeg) was adapted to the new +scheme. + + +The current prototype already solves the file caching problem +(and the severe memory leaks related). Now, I'll try to fix BUGs +using the tools that this new design provide. When I finish that, +it will be time to move the patch queue... But before I start +patching, I'll upload the prototype to the CVS server so it can +be tested. + +I only hope this design succeeds to provide what we need... + + +Jorge.- + + + +[Dillo-dev]Dillo Weekly News + +From: Allan Clark - 2000-10-24 14:53 + +I've just posted the latest Dillo weekly news, this was meant to be done on +Sunday so I'm sorry it's so late but I had a uni deadline to make (just). +Anyway you can find it at +http://www.shark.pwp.blueyonder.co.uk/news/news221000.html + +Allan Clark +allan@al... +shark@bl... + + + +Re: [Dillo-dev]Wild idea : frames + +From: Eric GAUDET - 2000-10-24 12:39 + +-- En reponse de "Re: [Dillo-dev]Wild idea : frames" de Eric GAUDET, le +24-Oct-2000 : +>>> Don't render frames embeding DwPages in DwPages, but +>>> create an actual browser page for each frame of the +>>> frameset, with the correct width and height. The +>>> user can then place the frames as he wants without +>>> being bugged with having to read a page in a tiny +>>> window. +>> +>> As I think about this, this sounds like a neat +>> approach for re-sizable frames. But bear in mind that +>> not all frames are re-sizable. We'll need to handle +>> both re-sizable AND non-re-sizable frames, IMHO. +>> +> +> While we could probably intercept resizing messages, I'm not sure +> this +> would be a good idea. I want to keep control over sites designed for +> large screens (I "only" have a 800x600 laptop). I don't see where in +> html concepts the user is denied to customised his browser's +> behavior. +> + +More precisely on attributes : +- NORESIZE should be used to allow the browser window to be +resized without the DwPage renegotiation its dimensions. (only useful +with sizes in %) +- SCROLLING should always be auto : there's no point to deny scrolling +in such a frame implementation. +- FRAMEBORDER, MARGINWIDTH, MARGINHEIGHT : ignored. I agree there will +be a problem here with complex pages using frames for showing fancy +displays, mostly for java applets and video streaming (none of which we +plan to support anytime soon). Those pages should be built with tables +anyway, and I don't care if we can't render "correctly" poorly designed +pages. + +This multi-window implementation for frames is allowed by HTML4 specs : +(quoted from W3C site) +"16.1 Introduction to frames +HTML frames allow authors to present documents in multiple views, +which may be independent windows or subwindows. Multiple views offer +designers a way to keep certain information visible, while other views +are scrolled or replaced." + +The "subwindows" is the way most browsers render frames, but not the +only one ;-) + +PS: I didn't came with this idea to make frames implementation simpler, +but because I think this could be convenient for users. + +----------------------------------- +Eric GAUDET +Le 24-Oct-2000 a 21:21:30 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Wild idea : frames + +From: Eric GAUDET - 2000-10-24 08:57 + +-- En reponse de "Re: [Dillo-dev]Wild idea : frames" de Daniel Roberts, +le 24-Oct-2000 : +> --- Eric GAUDET wrote: +>> Don't render frames embeding DwPages in DwPages, but +>> create an actual browser page for each frame of the +>> frameset, with the correct width and height. The +>> user can then place the frames as he wants without +>> being bugged with having to read a page in a tiny +>> window. +> +> As I think about this, this sounds like a neat +> approach for re-sizable frames. But bear in mind that +> not all frames are re-sizable. We'll need to handle +> both re-sizable AND non-re-sizable frames, IMHO. +> + +While we could probably intercept resizing messages, I'm not sure this +would be a good idea. I want to keep control over sites designed for +large screens (I "only" have a 800x600 laptop). I don't see where in +html concepts the user is denied to customised his browser's behavior. + +>> We'll also need to add an identifier for the +>> frameset (say a hash of the url ?), in case the same +>> target names are used in different framesets. That +>> doesn't seem pose any problem. +> +> Actually, would it not be easier if we simply embedded +> the DwPages within some master widget that contained +> the master URL and the master frameset? +> + +That's the current design "to-be" with Sebastian's new Dw widgets. + +> Also, another problem will surface in the course of +> this: How on earth do we plan to handle bookmarking, +> and back/forward buttons for frames? Last time I +> checked, the W3C HTML specs generally seemed to admit +> that this was a very messy situation in HTML. In +> Netscape, they had a HECK of a time with this. +> Bookmarking was impossible, and back/forward had to be +> given an ugly hack to handle frames, originally. +> + +For bookmarking, we can bookmark only the frameset's URL. For +back/forward button, I don't see any problem : each browser window +already has its own history. + +> In this course of thought, yet another thought has +> occured to me: With so many different +> languages/protocols (http, ftp, html, xml, xslt, css, +> JavaScript, etc.), why not make Dillo more generic and +> modular by breaking the HTML support out into a +> plugin? +> + +Plugins plan do handle all this (both protocols and languages). +However, we'll need a final rendering language, and IMHO html is not +worth than any other, and likely better designed than anything we can +design for scratch for our own use. +And plugins have a drawback, which was already addressed (in +Dillo-plugins protocol, to be plublished soon) about make a http plugin: +"While it is possible to override "http:", this unlikely to be a good +idea : doing that will cause Dillo to fork a Dillo-plugin for each http +request. While Dillo's main purpose is being an http client, it would +be much better to patch Dillo's http layer (instead of doing a +Dillo-plugin for that) if you want to modify/fix/enhance Dillo's http +behavior." + +Same for html : Dillo was designed for fast html rendering, we should +keep html inside Dillo as THE low-level language for pages rendering. + +> Speaking of which, BTW, whatever became of the FTP plugin? + +It's cooking, be patient. + +More on Dillo-plugins by friday. (protocol and design draft +documentation, patch, sample plugin and usable bookmark plugin) + +----------------------------------- +Eric GAUDET +Le 24-Oct-2000 a 17:39:29 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Wild idea : frames + +From: Daniel Roberts - 2000-10-24 01:53 + +--- Eric GAUDET wrote: +> Don't render frames embeding DwPages in DwPages, but +> create an actual browser page for each frame of the +> frameset, with the correct width and height. The +> user can then place the frames as he wants without +> being bugged with having to read a page in a tiny +> window. + +As I think about this, this sounds like a neat +approach for re-sizable frames. But bear in mind that +not all frames are re-sizable. We'll need to handle +both re-sizable AND non-re-sizable frames, IMHO. + +> We'll also need to add an identifier for the +> frameset (say a hash of the url ?), in case the same +> target names are used in different framesets. That +> doesn't seem pose any problem. + +Actually, would it not be easier if we simply embedded +the DwPages within some master widget that contained +the master URL and the master frameset? + +Also, another problem will surface in the course of +this: How on earth do we plan to handle bookmarking, +and back/forward buttons for frames? Last time I +checked, the W3C HTML specs generally seemed to admit +that this was a very messy situation in HTML. In +Netscape, they had a HECK of a time with this. +Bookmarking was impossible, and back/forward had to be +given an ugly hack to handle frames, originally. + +In this course of thought, yet another thought has +occured to me: With so many different +languages/protocols (http, ftp, html, xml, xslt, css, +JavaScript, etc.), why not make Dillo more generic and +modular by breaking the HTML support out into a +plugin? + +Speaking of which, BTW, whatever became of the FTP plugin? + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +[Dillo-dev]Wild idea : frames + +From: Eric GAUDET - 2000-10-24 01:23 + +The list is so sleepy, let me share with you an idea I had for +framesets rendering : (not inline frame, not tables) +Don't render frames embeding DwPages in DwPages, but create an actual +browser page for each frame of the frameset, with the correct width and +height. The user can then place the frames as he wants without being +bugged with having to read a page in a tiny window. +To make that working, we'll have to add in DwPage a target attribute : +I already did that in my href page. We'll also need to add an +identifier for the frameset (say a hash of the url ?), in case the same +target names are used in different framesets. That doesn't seem pose any +problem. +We can also render the frameset window showing a scalled-down version +of the frame map : gtk containers with buttons named after the frames +titles should fo the trick. A window-manager "pager" sort of thing. + +Any comment ? + +If you like the idea, I'll probably give it a try when next Dillo +version comes out. + +----------------------------------- +Eric GAUDET +Le 24-Oct-2000 a 10:12:56 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]BSD ports + +From: Sammy Mannaert - 2000-10-18 17:46 + +Jorge Arellano Cid wrote: + +> Sammy, +> +> +> On the DNS scheme concerns. That's the expected behaviour: one +> solving thread per request (Tested with more than a hundred +> simoultaneous requests crowding 4 server channels). +> +> It seems the problem is highly related to BSD's threads +> implementation; but please note that FreeBSD 3.5 does the trick. + +it's the expected behaviour of gethostbyname() actually (that it garbles + +up it's internal data when called simultaneously in threads). i think +the thing here is that glibc might automatically use a multithread +capable +gethostbyname (which isn't one of the *_r functions specified by posix). + +i did a little research today and found out that most unices have a +gethostbyname_r function, but apparently BSD hasn't (because the +function isn't standardized yet). + +dillo runs fine when i put the max number of server channels to 1, so +i'll use that for now :) + + +> +> Hope this helps +> Jorge.- +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]BSD ports + +From: Jorge Arellano Cid - 2000-10-18 12:30 + +Sammy, + +Kurt Lidl reported no problems using dillo with his BSD/OS +4.0.1 i386system . + +Ryan Oberlin got it running on +FreeBSD (with some changes that I haven't got). + +tjs17@co... reported no problems with a a 32bit machine, +gcc 2.7.2.3 and FreeBSD 3.5 (with -pthread instead of -lpthread). + +Jeremy C. Reed has reported some +problems trying to run dillo on NetBSD (I'm sure he'll appreciate +any helping information). + +Feel free to contact and ask them (please tell them I gave you +the addresses). + +--- + +On the DNS scheme concerns. That's the expected behaviour: one +solving thread per request (Tested with more than a hundred +simoultaneous requests crowding 4 server channels). + +It seems the problem is highly related to BSD's threads +implementation; but please note that FreeBSD 3.5 does the trick. + + +Hope this helps +Jorge.- + + + +Re: [Dillo-dev]bug with dns or .. ? + +From: Sammy Mannaert - 2000-10-17 21:20 + +Allan Clark wrote: + +> Just tried it and it worked fine for me. +> +> + +i have found what the problem is. apparently we are doing something +quite dangerous here :) + +in Dns_server we call gethostbyname() + +from manpage gethostbyname +These functions use static data storage; if the data is needed for future + +use, it should be copied before any subsequent calls overwrite it. + +but what we do is: we run Dns_Servers (several of them) in threads. +so it is quite possible that one query starts while another one is busy and +it will garble up gethostbyname's internal data (which is what's happening) + +when i disable threading for dns i have no problems. + +the debug output i get is for example : + +a_Cache_open_url: +http://images.freshmeat.net/FreshMeat/Core/pc.gif?/index.php3,971817463 +a_Cache_open_url: http://phoenix-adrunner.mycomputer.com/b/ar/freshmeat1/1 +Dns_server: starting... +channel: 0 +Dns_server: starting... +channel: 1 +a_Cache_open_url: http://ads.freshmeat.net/egra5006en.gif?971817463 + +etc ... etc .. + +from this point no single gethostbyname function will return !! note that we +had two +requests very fast after eachother. + + + +RE: [Dillo-dev]bug with dns or .. ? + +From: Allan Clark - 2000-10-17 20:34 + +Just tried it and it worked fine for me. + +> -----Original Message----- +> From: dillo-dev-admin@li... +> [mailto:dillo-dev-admin@li...]On Behalf Of Sammy +> Mannaert +> Sent: 17 October 2000 21:14 +> To: Dillo-dev@li... +> Subject: [Dillo-dev]bug with dns or .. ? +> +> +> hi, +> +> as i don't know if this is a bug or not, i want to ask some of you who +> run dillo on linux: +> +> - go to http://www.freshmeat.net (or freshmeat.net) +> - try to click any of the links above (linux.com, slashdot, etc ..) +> - you will only see DNS resolving and that's it .. +> +> as i am running dillo on freebsd, i'm aware this might be a freebsd +> specific +> thingie, so i'd like to see if it's also happening on a linux platform. +> +> +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]bug with dns or .. ? + +From: Sammy Mannaert - 2000-10-17 20:25 + +hi, + +as i don't know if this is a bug or not, i want to ask some of you who +run dillo on linux: + +- go to http://www.freshmeat.net (or freshmeat.net) +- try to click any of the links above (linux.com, slashdot, etc ..) +- you will only see DNS resolving and that's it .. + +as i am running dillo on freebsd, i'm aware this might be a freebsd +specific +thingie, so i'd like to see if it's also happening on a linux platform. + + + +[Dillo-dev]Find text (quite long sorry) + +From: Allan Clark - 2000-10-17 16:10 + +Hi, +First of all I am having trouble with my network, I seem to be able to send +and recieve mail and that is about it, anyway that is why this is not a patch +but I have just included the text, there isn't much anyway and is all in one +function but sorry about that. The code below cleans up the findtext implemented +by Sam, it uses a pretty fast algorithm which will also work if we ever choose +to use unicode characters. You should be able to follow the algorithm fairly +easily but essentially it pre-computes a prefix function for the find string +this it does in linear time according to the length of the find string and only +depends on the search string and not the page's text, it then searches through +the text of the page which can also be done in linear time, and so it is pretty +fast. This will find text that is span over one or more lines, but there is one +slight known problem, this concerns moving the scroller to the correct +position, currently if the occurence of the find string is in one line then the +correct thing happens, if it spans two lines then again the correct thing +happens and the scroller is positioned as if it were only contained in the top +of the two lines, but if it spans more than two lines the scroller is placed as +if the occurence started at the second last line the the occurence spans. Other +points to note is that I have included code to enable the user to either match +the case or not, I haven't updated the rest of the code as I realised because +of my strange network problem I wouldn't be able to patch so I wanted to keep +my changes limited to one function. Also the foundAt variable gives us a little +more information than it needs but I +left it the way it is as it will make it easier to highlight the text when we +add support for that. Okay so if you're still with me, apply Sam's patch +http://www.shark.pwp.blueyonder.co.uk/patches/findtext.diff.gz +then Sebastian's patch +http://www.shark.pwp.blueyonder.co.uk/patches/findtext2.diff +and then open up dw_page.c, scroll to the bottom where you will find the +a_Dw_page_find_text(DwPage *page, char *find) function and replace it with the +one below + +/* +* Find the text in the page. +*/ +void a_Dw_page_find_text(DwPage *page, char *find) +{ + +GString *stext; +GtkDwScroller *scroller; +DwContainer *container; +gint m; +gint *prefix; +gboolean matchCase; +gint k = 0; +gint q = 1; +gint line_num = 0; +gint foundAt = -1; +gint ii = 0; +gint t = 0; +gint s = 0; +gint fromPrevious = 0; + + +matchCase = FALSE; /* Not yet implemented */ + +if ( !(container = a_Dw_find_container(&page->dw)) ){ +g_print("BUG: Dw container not found\n"); +return; +} + +m = strlen(find); +if (!m) +return; + +prefix = (gint*) g_malloc (m * sizeof(gint)); +stext = g_string_sized_new(64); + +/* First compute a static prefix function +* this can be done in linear time and +* based solely on the search string +*/ + +prefix[0] = 0; /*Must be this reguardless of the string */ + +if (!matchCase) +g_strdown (find); + +for (q = 1; q < m; q++) +{ +while (k > 0 && find[k] != find[q]) +k = prefix[k - 1]; +if (find[k] == find[q]) +k++; +prefix[q] = k; +} + +/*Go in loop searching each line until we find +the search string */ +for (line_num = 0; line_num < page->num_lines; line_num++) +{ +/* this allows us to find strings that span over two or more lines */ +if (stext->len > m) +stext = g_string_erase(stext, 0, stext->len - m); +fromPrevious = stext->len; /*might not be as long as m */ +/* Now we get the next block of text */ +for(s = 0; s < page->lines[line_num].num_words; s++) +{ +if (page->lines[line_num].words[s].content_type != DW_PAGE_CONTENT_TEXT) +continue; +stext = g_string_append(stext, page->lines[line_num].words[s].content.text); +stext = g_string_append(stext, " "); +} +if (stext->len < m) +continue; + +/* Now we search the stext for the search string */ +if(!matchCase) +stext = g_string_down(stext); +foundAt = -1; +ii = 0; +t = 0; +while (stext->str[ii]) +{ +while (t > 0 && (find[t] != stext->str[ii])) +t = prefix[t - 1]; +if (find[t] == stext->str[ii]) +t++; +ii++; +if (t == m) { +foundAt = ii - m; +break; +} +} +/* Now if we have found it then highlight the line */ +if (foundAt != -1) { +scroller = GTK_DW_SCROLLER (container->widget->parent); +if (foundAt < fromPrevious && line_num > 0) /*line_num <= 0 shouldn't ever happen if foundAt < fromPrevious*/ +a_Dw_gtk_scroller_jump_pos (scroller, +page->lines[line_num - 1].y_top); +else +a_Dw_gtk_scroller_jump_pos (scroller, +page->lines[line_num].y_top); +break; +} +} + +g_string_free(stext, TRUE); +g_free (prefix); +} + + + +Re: [Dillo-dev]Patches + +From: Sebastian Geerken - 2000-10-17 12:23 + +Eric GAUDET wrote: +> I've already included in most of the pages I made if dillo v0.2.4's behavior is +> correct or not, and sometime what it should be. I planned to update this when +> next version (not cvs) will be available. +> It's an HTML-rendering testsuite only. I won't build any testsuite for cache +> behavior, http requests and other things a browser is supposed to do. +> I understood there's a bedtest for Sebastian's new Dw : I can include that. + +It's simply a main-function of 20 lines, which creates some widgets +and then calls gtk_main. It helps me testing all functions and finding +bugs. (Furthermore, most widgets aren't ported yet, although they are +mostly simple ones, like DwBullet.) This could perhaps done also for +other modules, i.e. separating the module's code and calling all of +its functions "by hand". + +Another way could be to use the existing possibilities of a server. +E.g., I already used php pages with included "" to +simulate slow connections (this could also be done by a simple cgi +script), or you may create specific http headers etc. + +> It's the very first version : no one has reacted on it yet. I expect to receive +> your own pages, comments and (grammar :-/) corrections so it can be improved. +> (actually I was waiting for Jorge's green light and corrections before +> publishing it, but you guys may want to know what's happening ;-) + +I have written some test pages. I'll download your suite and look what +I might send you. + +Sebastian + + + +Re: [Dillo-dev]Patches + +From: Livio Baldini Soares - 2000-10-17 01:41 + +Jorge Arellano Cid writes: +> +> Hi! +> +> The minimal consideration I expect from newcomers, is to read +> the home page before posting to this mailing list. If they don't +> or even worse, they do but decide to force their ways into this +> project, we have a bad start... +> +> Rules are there for a reason, and I want to thank Eric for +> pointing them out to the mailing list. +> + +Ok, sorry. I didn't mean to break all your "rules" and cause any +confusion. I was just trying to contribute, and not "forcing" my way +into the project. I did read the home page, and read a bunch of +previous mails from the archive list, but it wasn't clear to me that +we weren't suppossed to post patches and stuff in the mailing +list. Now it's very clear, sorry. + +(...) + +> > Sorry if I seemed annoyed, but I not. It just not nice to have +> > people effort thrown away in vain, when they could be producing lots +> > if things were a little bit more organized. +> +> Please don't blame on us the results of you not following our +> rules. You could have known that in advance. As a matter of fact, +> you knew I was working some of the bugs you tried to fix. + +Wow, I wasn't blaming anyone of anything, I was just stating my +opinion about how the project was organized. But since am a newcomer, +and don't nothing about it, you can just ignore my remarks ;-). + +> +> If you read the mailing list archives, you'll find an +> "Activity" post (by me); there you'll find a list of things that +> your patch doesn't solve, and maybe then it will become clear why +> patches are reviewed before inclusion. + +I agree with this, all patches should be reviewed. I was just +exposing an idea I had about the problem (not a total fix). I sent the +patch to show to everyone the idea I had, and wanted some feed back +about the *idea*, I know that the patch didn't solve all the problems, +and I don't expect it to be included in Dillo's next version. + + +I'm REALLY sorry that I caused all this commotion, I did not mean to +have a "bad start". Jorge, what should I do to "redeem" my situation? + +best regards, + +-- +Livio + + + +Re: [Dillo-dev]how i compiled under freebsd (4.1) + +From: Sammy Mannaert - 2000-10-17 00:10 + +Sammy Mannaert wrote: + +> i'm not a freebsd expert by far, but i think this explenation offers +> more detail than +> the readme in the tarball .. (for example it doesn't add the problem of +> -D_THREAD_SAFE, +> if you forget it, dillo will only load the first url you go to, the +> other ones will only +> display "resolving DNS" or something alike in the statusbar) +> + +it seems as if this isn't really fixed yet (though i used correct +compiling options ..) sometimes (quite a lot really) i get DNS +solving and nothing else ... weird ... + +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + + + +[Dillo-dev]how i compiled under freebsd (4.1) + +From: Sammy Mannaert - 2000-10-16 23:38 + +hi, + +i've succesfully compiled and tested dillo on freebsd (the platform i +run now) +in order to be able to compile, i had to do quite a few things which i +will explain +here. + +i'm not sure if i took the "correct" freebsd way of doing things +however .. + +first step: freebsd uses -pthread and -D_THREAD_SAFE instead of +-lpthread +and -D_REENTRANT : +type +export CFLAGS="-pthread -D_THREAD_SAFE" +or setenv CFLAGS "-pthread -D_THREAD_SAFE" +(depending on shell) + +second step: freebsd uses gtk12-config instead of gtk-config : +do +ln /usr/X11R6/bin/gtk12-config /usr/X11R6/bin/gtk-config +(as root ofcourse) + +third step: +do +./configure --with-gtk-prefix=/usr/X11R6 +--with-gtk-exec-prefix=/usr/X11R6 + + +now here is when a problem emerges. it seems our configure script +doesn't really +support the option to set the jpeg include lib directories ? (for the +record: freebsd +has jpeglib.h etc .. in /usr/local/include) .. anyways, i couldn't get +it to work :) +what i did: +in configure.in i outcommented following part: +if test "$jpeg_ok" = yes; then +AC_CHECK_HEADERS(jpeglib.h jconfig.h jerror.h jmorecfg.h, +jpeg_ok=yes, jpeg_ok=no) +fi + +it then worked as suspected. (do we really need this part ? can't we +assume that +the jpeglib is correctly installed after we did the first test in +configure ? +checking for jpeg_destroy_decompress in -ljpeg (<- this one)) + + +i'm not a freebsd expert by far, but i think this explenation offers +more detail than +the readme in the tarball .. (for example it doesn't add the problem of +-D_THREAD_SAFE, +if you forget it, dillo will only load the first url you go to, the +other ones will only +display "resolving DNS" or something alike in the statusbar) + + + +[Dillo-dev]help needed: sigsuspend with new glibc + +From: Eric GAUDET - 2000-10-16 16:49 + +Hi all, +I've updated my glibc to 2.1.3-5mdk a few days ago, and now I'm catching a lot +of sigsuspend in gdb (I hadn't a single one before) : on sigsuspend every +pthread_create (one for each image on a page). That's really bugging me. +What can I do to avoid this ? + +Does this have anything to do with that message : +(gdb) run +Starting program: /home/eric/src/dillo-0.2.4.orig/src/./dillo +warning: Unable to find dynamic linker breakpoint function. +GDB will be unable to debug shared library initializers +and track explicitly loaded dynamic code. +dillo_dns_init: Here we go! + +Can anyone help me on this ? + +----------------------------------- +Eric GAUDET +Le 17-Oct-2000 a 01:43:21 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Patches + +From: Eric GAUDET - 2000-10-16 16:34 + +-- En reponse de "RE: [Dillo-dev]Patches" de Daniel Roberts, le 16-Oct-2000 : +>> It's an HTML-rendering testsuite only. I won't build +... +> [extra deleted for brevity...] +> +> I just took a look at it. At the moment, it does look +> to me like a reasonable subset of HTML tests, given +> Dillo's current status/capabilities. When +> tables/frames support is complete, I am guessing that +> tables/frames tests will be the next thing to be +> added. :-) +> + +Sure, but Jorge already urged me *not* to bother with table testing pages, as +the first line of code for it is not even written. +But that's the next big step all right. + +> BTW, Mozilla has a *HUGE* test suite, with tests +> scattered all over the place. I suggest we might want +> to consider using some of these tests. I'd be willing +> to bring them over here and adapt them for Dillo's +> use, if you'd like to add them to your testsuite. + +That would be nice. Just focus on dillo's current/likely next capabilities for +now. + +> When the time comes, Mozilla also has XML, CSS, and +> JavaScript tests as well. They are good and complete, +> what's more. +> + +Forget it, we won't need them soon. + +> I think however that we *DO* also need things like +> http requests, cache behavior, and other things a +> browser should do. + +That's not easy to publish this as a test suite : who here has an http server +running on his machine ? Who wants to patch, say boa, for faking altered http +responses to see how dillo's handling the problem, and maintain such a +malformed monster ? How helping would it be : everyone having the same +behaviour in a tight controlled environment and make sure dillo's working ok ? + +What can be done, though, is one (or some) of us publish some results. +But the most likely guy doing that is the feature-coder himself, with his own +tests. And I'm sure he won't submit a non-fully tested patch. + +I'm not sure there's a point doing a test suite for this now. When dillo reach +v1.0 and everyone will be willing to add nigty feature, then we'll want to make +sure we won't break anything. + +For now, I mainly want to test what I'm adding, relying on others to do the +same for what they're doing. + +> For example, how about the +> bookmark bug that someone pointed out was fixed THREE +> times? A regression test on this should have helped +> point this out earlier. :-) + +The bookmark thing was always alpha code. It's a quick hack nobody wants to fix +because : +1) there's a lot to do elsewhere +2) there's a bookmark as pluggin planned since day one, better, easier to fix, +external to dillo, hopefully making obsolete the current fishy code. + +> However, since I actually +> probably know HTML and CSS better than I do XML or C, +> I will probably be able to do these most readily. +> +[2nd post] +> I would definitely be willing to perform the tests, +> given the links Eric just posted. + +If you want to maintain the Html testsuite thing, help yourself. You can take +what I made and mix it with whatever you think is relevant. Or we can both +update it. + +> Also, with Gzilla/Armadillo, I used to post Insure++ +> memory leak reports sometimes. I can do the same for +> Dillo if it helps. + +That would be great ! + +----------------------------------- +Eric GAUDET +Le 17-Oct-2000 a 01:11:01 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Patches + +From: Daniel Roberts - 2000-10-16 15:20 + +--- Jorge Arellano Cid wrote: + +> I've read Daniel's posts on the subject and if +> he's willing to perform the tests (or any one +> else), please contact Eric and start working from +his +> test-suite. + +I would definitely be willing to perform the tests, +given the links Eric just posted. + +Also, with Gzilla/Armadillo, I used to post Insure++ +memory leak reports sometimes. I can do the same for +Dillo if it helps. + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +RE: [Dillo-dev]Patches + +From: Daniel Roberts - 2000-10-16 15:17 + +--- Eric GAUDET wrote: + +> It's an HTML-rendering testsuite only. I won't build +> any testsuite for cache behavior, http requests and +> other things a browser is supposed to do. +> I understood there's a bedtest for Sebastian's new +> Dw : I can include that. +> It's the very first version : no one has reacted on +> it yet. I expect to receive your own pages, comments +> and (grammar :-/) +> corrections so it can be improved. +[extra deleted for brevity...] + +I just took a look at it. At the moment, it does look +to me like a reasonable subset of HTML tests, given +Dillo's current status/capabilities. When +tables/frames support is complete, I am guessing that +tables/frames tests will be the next thing to be +added. :-) + +BTW, Mozilla has a *HUGE* test suite, with tests +scattered all over the place. I suggest we might want +to consider using some of these tests. I'd be willing +to bring them over here and adapt them for Dillo's +use, if you'd like to add them to your testsuite. +When the time comes, Mozilla also has XML, CSS, and +JavaScript tests as well. They are good and complete, +what's more. + +I think however that we *DO* also need things like +http requests, cache behavior, and other things a +browser should do. For example, how about the +bookmark bug that someone pointed out was fixed THREE +times? A regression test on this should have helped +point this out earlier. :-) However, since I actually +probably know HTML and CSS better than I do XML or C, +I will probably be able to do these most readily. + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +RE: [Dillo-dev]Patches + +From: Eric GAUDET - 2000-10-16 12:34 + +-- En reponse de "[Dillo-dev]Patches" de Jorge Arellano Cid, le 16-Oct-2000 : +> Regression tests: +> ----------------- +> +> Some time ago Eric commited to compiling a test-suite for dillo +> (we discussed several topics and its ready). I've had no time to +> test it, nor to include it in official plans (due to lack of +> time, --I sincerely apologize Eric). +> + +No problem : I much prefer you working on dillo's next version ;-) + +> I've read Daniel's posts on the subject and if he's willing to +> perform the tests (or any one else), please contact Eric and +> start working from his test-suite. +> + +I've already included in most of the pages I made if dillo v0.2.4's behavior is +correct or not, and sometime what it should be. I planned to update this when +next version (not cvs) will be available. +It's an HTML-rendering testsuite only. I won't build any testsuite for cache +behavior, http requests and other things a browser is supposed to do. +I understood there's a bedtest for Sebastian's new Dw : I can include that. +It's the very first version : no one has reacted on it yet. I expect to receive +your own pages, comments and (grammar :-/) corrections so it can be improved. +(actually I was waiting for Jorge's green light and corrections before +publishing it, but you guys may want to know what's happening ;-) + +Here's a link where anyone can visite : +http://www.rti-zone.org/dillo/Html.testsuite/ + +Here's where you can download the whole suite : +http://www.rti-zone.org/dillo/Html.testsuite.tar.gz + +----------------------------------- +Eric GAUDET +Le 16-Oct-2000 a 21:19:43 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Patches + +From: Jorge Arellano Cid - 2000-10-16 11:49 + +Hi! + +The minimal consideration I expect from newcomers, is to read +the home page before posting to this mailing list. If they don't +or even worse, they do but decide to force their ways into this +project, we have a bad start... + +Rules are there for a reason, and I want to thank Eric for +pointing them out to the mailing list. + + +> It would be really nice if we had an updated CVS version to patch +> to, or if someone (one of the olders guys with the project) released a +> 0.2.5 or 0.2.4-1 or something like that, with all the "pending" +> patches included, cause frankly it seems too confusing and I have no +> idea where to start programming so my works are all wasted/outdated. + +The CVS version is the most current (official). +Developers can patch 0.2.4 (or CVS). + +> Sorry if I seemed annoyed, but I not. It just not nice to have +> people effort thrown away in vain, when they could be producing lots +> if things were a little bit more organized. + +Please don't blame on us the results of you not following our +rules. You could have known that in advance. As a matter of fact, +you knew I was working some of the bugs you tried to fix. + +If you read the mailing list archives, you'll find an +"Activity" post (by me); there you'll find a list of things that +your patch doesn't solve, and maybe then it will become clear why +patches are reviewed before inclusion. + +Finally, I'll keep my schedule exactly as described in the +"Activity" post. + +--- + +Bug track engine: +---------------- + +I see one source of confussion (and a solution) here. + +I'll use the word "done" to signal a CVS commited patch. +Developers, please only use comments or a percentage. + +Example: + +MrX@so... 70% <- The guy is making some progress + +MrX@so... 100% <- The guy is finished his work and the +patch is expecting a review. + +MrX@so... 100% done <- The patch was reviewed (fixed) and +commited to the CVS. + + +---- + +Regression tests: +----------------- + +Some time ago Eric commited to compiling a test-suite for dillo +(we discussed several topics and its ready). I've had no time to +test it, nor to include it in official plans (due to lack of +time, --I sincerely apologize Eric). + +I've read Daniel's posts on the subject and if he's willing to +perform the tests (or any one else), please contact Eric and +start working from his test-suite. + + +---- + +News: +----- + +I want to thank Allan for his excellent work with dillo weekly +News. + + + +Sincerely +Jorge.- + + + +Re: [Dillo-dev]About bugs #74 and #69 (better program and watch + +From: Eric GAUDET - 2000-10-16 11:12 + +-- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and +watch" de Livio Baldini Soares, le 16-Oct-2000 : +>> Looks nice. I can't really test it, because my cable modem loads pages too +>> fast +>> and I can barely see the watch ;-) I wanted to see if one can scroll in a +>> partially loaded page, but I can tell really. +>> However, it seems not to wait until all images on a page are loaded, is it +>> the expected behavior ? +> +> Err, it's suppossed to do that. The watch serves so one can control +> when the lock was ON or OFF, not when/while all the page was +> loading. I did that cause sometimes the lock would go ON and wouldn't +> go off like it should (like when a page is not found or some other +> error, which currently the lock system isn't implemented to work +> on). So if the cursor continued to be the watch for no reason, just +> hit the STOP button, and everything should go back to normal. +> + +I'm asking because it seems to segfault too when clicking a link (or the +button "back") on a page where all images are not loaded yet. Wasn't it +supposed to protect from that too ? + +>> I experienced some segfaults too. I can't reproduce them each time, but it +>> seems to occur when closing a window where a page (an image ?) is still +>> loading. +>> +> +> Yeah, I get that too, but as Sebastian said, closing windows are not +> that simple... there's a need for a little bit of cleaning up, or else +> pending requests don't have a place to go, then they get sad and crash +> Dillo ;-) +> + +Ok, makes sens. So, is the windows closing code going to be your next patch ? +;-)) + +----------------------------------- +Eric GAUDET +Le 16-Oct-2000 a 20:07:27 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]About bugs #74 and #69 (better program and watch + +From: Livio Baldini Soares - 2000-10-16 09:28 + +Eric GAUDET writes: +> -- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and +> watch " de Livio Baldini Soares, le 16-Oct-2000 : + +> ... +> Looks nice. I can't really test it, because my cable modem loads pages too fast +> and I can barely see the watch ;-) I wanted to see if one can scroll in a +> partially loaded page, but I can tell really. +> However, it seems not to wait until all images on a page are loaded, is it the +> expected behavior ? + +Err, it's suppossed to do that. The watch serves so one can control +when the lock was ON or OFF, not when/while all the page was +loading. I did that cause sometimes the lock would go ON and wouldn't +go off like it should (like when a page is not found or some other +error, which currently the lock system isn't implemented to work +on). So if the cursor continued to be the watch for no reason, just +hit the STOP button, and everything should go back to normal. + +> I experienced some segfaults too. I can't reproduce them each time, but it +> seems to occur when closing a window where a page (an image ?) is still loading. +> + +Yeah, I get that too, but as Sebastian said, closing windows are not +that simple... there's a need for a little bit of cleaning up, or else +pending requests don't have a place to go, then they get sad and crash +Dillo ;-) + +> +> please don't include the whole old messages. + +Oops, :-o forgot to cut it, sorry. + +bye, + +-- +Livio + + + +Re: [Dillo-dev]About bugs #74 and #69 (better program and watch + +From: Eric GAUDET - 2000-10-16 09:11 + +-- En reponse de "Re: [Dillo-dev]About bugs #74 and #69 (better program and +watch " de Livio Baldini Soares, le 16-Oct-2000 : +> Hi yall, +> +> I've been working on my patch, to better it. First thing I wanted to +> make the cursor change into a watch or something while the lock (which +> I mention below) was on. To do is I started messing more with the code +> and realized that the lock system which I created was starting to turn +> into a headache. So what I did was, I encapsulated the system into +> basically two calls (which I included into nav.c): +> +... +Looks nice. I can't really test it, because my cable modem loads pages too fast +and I can barely see the watch ;-) I wanted to see if one can scroll in a +partially loaded page, but I can tell really. +However, it seems not to wait until all images on a page are loaded, is it the +expected behavior ? +I experienced some segfaults too. I can't reproduce them each time, but it +seems to occur when closing a window where a page (an image ?) is still loading. + +> +> Attached is the gzipped patch, which should deprecate the previous I +> sent. I don't know if this will help in the future, maybe Jorge will +> sanitate all our problems with his new misterious Dw ;-). But until +> then, I think this is a nice working patch. What do guys think? +> + +anyway that's a nice patch : I can't speak for Jorge, and I'm not so much in +page-loading/caching stuff, but the concept seems good. + +> bye, +> +> Livio. +> +> Livio Baldini Soares writes: +>> Hi (again), +>> +... + +please don't include the whole old messages. + +bye + +----------------------------------- +Eric GAUDET +Le 16-Oct-2000 a 18:00:54 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]File baseurl resolving behaviour + +From: Livio Baldini Soares - 2000-10-16 05:15 + +Hi guys, + +again browsing in Dillo I tried to do the following; I wanted to +check the contents of my /tmp directory, so I typed in: +/tmp/ + +on the "New Url", instead of file:/tmp/. Dillo assumed that it was a +http request and tried to resolve http://tmp/. + +Im my opinion, this shouldn't happen. I think that if a user enters +an URL starting with a '/' then he wants a file not a http. What do +you guys think? + +Anyway, I've already made the patch (its really small), and am +sending along with the message. + +bye, + +-- +Livio + +--- dillo.orig/src/interface.c Sat Sep 9 21:08:36 2000 ++++ dillo.my/src/interface.c Mon Oct 16 03:06:12 2000 +@@ -654,7 +656,7 @@ Interface_openfile_ok_callback(GtkWidget +*/ +void a_Interface_entry_open_url(GtkWidget *widget, BrowserWindow *bw) +{ +- gchar *url; ++ gchar *url, *BaseUrl; +GtkEntry *entry; + +/* Find which entry to get the URL from. This is a bit of a hack. */ +@@ -666,7 +668,13 @@ void a_Interface_entry_open_url(GtkWidge +#ifdef VERBOSE +g_print(ëntry_open_url %s\n", gtk_entry_get_text(entry)); +#endif +- url = a_Url_resolve_relative("http:/", gtk_entry_get_text(entry)); ++ if ( (gtk_entry_get_text(entry))[0] == '/') /* if the first char is a slash, */ ++ BaseUrl = "file:"; /* the user wants a file. */ ++ else ++ BaseUrl = "http:/"; ++ ++ url = a_Url_resolve_relative(BaseUrl, gtk_entry_get_text(entry)); ++ +if ( url ) { +a_Nav_push(bw, url); +g_free(url); + + + +Re: [Dillo-dev]About bugs #74 and #69 (better program and watch cursor feature) + +From: Livio Baldini Soares - 2000-10-16 03:02 + +Attachments: seg_fault2.diff.gz + +Hi yall, + +I've been working on my patch, to better it. First thing I wanted to +make the cursor change into a watch or something while the lock (which +I mention below) was on. To do is I started messing more with the code +and realized that the lock system which I created was starting to turn +into a headache. So what I did was, I encapsulated the system into +basically two calls (which I included into nav.c): + +a_Nav_lock_acquire +a_Nav_locl_release + +And except for some early BrowserWindow initilization, these are +what you should call, and never access bw->nav_lock directly (like a +private in C++). This way the code looks much better, and easier to +understand and expand. + +With this done I was able to successfully implement the little +"loading watch" which I wanted (it was getting on my nerves not +knowing what Dillo was doing, if it was loading the page or not, +etc. with this watch cursor a now the lock is acquire threfore +*should* be indicating that it's loading a root-Url). + +Attached is the gzipped patch, which should deprecate the previous I +sent. I don't know if this will help in the future, maybe Jorge will +sanitate all our problems with his new misterious Dw ;-). But until +then, I think this is a nice working patch. What do guys think? + +bye, + +Livio. + +Livio Baldini Soares writes: +> Hi (again), +> +> I know that Jorge is working on these bugs, but I *think* I've found +> a good solution to the problems (actually I'm not really sure...). It +> seems to me that the problem comes from a type of "concurrency" +> problem within the IO and html/cache modules. The http requests in +> Dillo, from what I understand, are all asynchronous, but I've seen no +> concurrency controls in the modules. I think this lack of control is +> generating the problem. +> +> For example, if I press the "Achieved Goals" link in Dillo's home +> page, don't wait for it to load and press the "Changelog" link (or any +> other, even the "Acheived Goals" repeatelly), Dillo will request ALL +> the "clicked" links pages. Up to this part everything should be ok +> (actually no, but I'll get to that later), the problem comes in when +> the requests arrive. Many requests start coming in and Dillo gets +> "confused" and can't handle them all. +> +> What I've done is prevented various (root) Url requests at the same +> time. This is what Netscape does, when you click a link on a page, the +> cursos turns into a watch and all the other links become +> "un-clickable" until the new page gets loaded. I think this is a +> "correct" behaviour and not a restriction to the user. +> +> I did this in Dillo by placing a type of LOCK in the BrowserWindow +> (browser.h) structure. Its a gboolean `nav_lock`. When someone tries +> to load a root-url, by using the `a_Nav_push` I set the nav_lock to +> TRUE. By doing this I disabled any type of user navigation. The only +> two places where `nav_lock` comes FALSE again is by pressing STOP (in +> the `a_Commands_stop_callback) and in the `a_Nav_expect_done` +> function, because here we can assume that the root url has changed +> (bw->nav_stack[nav_stack_ptr]) and therefore we can allow the user to +> navigate savely again. +> +> When I got this working I would still (very seldomly) get +> seg. faults. Studying the problem I found out that if, for example, +> you click on a link, then wait until it get "unlocked" (when the +> `a_expect_done` is called), then press BACK before the entire page +> loaded (pics and all), a few pending requests for that page are still +> coming in. With that in mind, I tought of two choices: +> +> 1) Everytime the user requested for an URL, Dillo should cancel all +> the pending requests for old URLs, so that the requests wouldn't +> arrive later "unexpectedly". +> +> 2) Don't cancel the requests since Dillo has already made then; I +> think it would be a wast of data. Instead just ignore the few pending +> requests. +> +> I chose option 2. I did this similar to what Sam Dennis did a while +> ago (when he send the patch). From what I can see applying these two +> ideas (the lock and Sam's patch) we have a pretty much clean fix to +> the problem. Of course I could be wrong and missing the "root" of the +> problem. Does anybody see any flaws in what I've described above? +> +> This lock system, if it's conceptually correct, should fix this +> bug. But what I've implemented is NOT the complete lock system, it's +> just a preview on how I tought to fix this problem. If you guys like +> the idea, I'll have to finish up the exception handling (so if there's +> an error while downloading a page, navigation doesn't become forever +> disabled, erroneously locked). +> +> I'm sending the patch that should implement this fix, included is +> Sam's patch (html_loading.diff) and the cache patch (cache_patch), so +> there's no need to apply those patches, only this one. This patch +> should be applyed against the CVS version. +> +> hope this helps, bye, +> +> -- +> Livio + + + +RE: [Dillo-dev]Where's bug #80 fix? + +From: Eric GAUDET - 2000-10-16 01:59 + +-- En reponse de "RE: [Dillo-dev]Where's bug #80 fix?" de Eric GAUDET, le +16-Oct-2000 : +> If you want to test all my patches, here's an (temporary, don't rely on it) +> address where you can download all of them with a txt file of explanations : +> + +Sorry, here's the address : +http://www.rti-zone.org/dillo/ + +----------------------------------- +Eric GAUDET +Le 16-Oct-2000 a 10:58:42 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Where's bug #80 fix? + +From: Eric GAUDET - 2000-10-16 01:28 + +-- En reponse de "[Dillo-dev]Where's bug #80 fix?" de Livio Baldini Soares, le +15-Oct-2000 : +> Hello, +> +> I saw in the Bug Engine that bug #80 (seg. fault, when right +> clicking in a text/plain page) was taken cared of. If I recall +> correctly it stated that Eric fixed it, but I can't seem to find +> anything about it in the mail archive, nor any of Allan's patches +> contain a solution for it. Anybody know how's the fix? Eric? +> +> bye, +> + +I always send my patches t directly to Jorge, not to the mailing list, because +that's what Jorge asked. +If you want to test all my patches, here's an (temporary, don't rely on it) +address where you can download all of them with a txt file of explanations : + +----------------------------------- +Eric GAUDET +Le 16-Oct-2000 a 10:20:19 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Where's bug #80 fix? + +From: Livio Baldini Soares - 2000-10-15 20:17 + +Hello, + +I saw in the Bug Engine that bug #80 (seg. fault, when right +clicking in a text/plain page) was taken cared of. If I recall +correctly it stated that Eric fixed it, but I can't seem to find +anything about it in the mail archive, nor any of Allan's patches +contain a solution for it. Anybody know how's the fix? Eric? + +bye, + +-- +Livio + + + +Re: [Dillo-dev]Close Window command + +From: Livio Baldini Soares - 2000-10-15 20:07 + +Sebastian Geerken writes: +> Livio Baldini Soares wrote: +(...) +> +> There is a function a_Interface_new_browser_window, so there should +> probably also be a function a_Interface_destroy_browser_window, which +> will do a bit more that destroying the widget. Merely destroying the +> widget could even cause crashes (AFAIK dillo), since the still active +> IO stuff could try to add text into the nonexisting page widget. + +Oops, guess your right... sorry. So we don't "forget" to do this, I +inserted this as a Bug in the Bug Engine, it's bug #87. + +bye, + +-- +Livio + + + +Re: [Dillo-dev]Old CVS + +From: Daniel Roberts - 2000-10-15 19:56 + +--- Sam Dennis wrote: +> Correct me if I'm wrong, but isn't an out of date +> cvs version an oxymoron? +> +> It seems like it's extremely difficult to avoid +> repeating work currently +> because patches have been made but the cvs version +> hasn't changed. + +I agree. Question is, why are the patches not being +committed to CVS? I would think the thing to do it +have them checked in, after undergoing a code review. +Then we wouldn't have this problem. Besides, if a +change is found later to cause problems, it can be +backed out. Again, some kind of automated regression +testing infrastructure would make this part easier, too. + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +[Dillo-dev]Old CVS + +From: Sam Dennis - 2000-10-15 19:32 + +Correct me if I'm wrong, but isn't an out of date cvs version an oxymoron? + +It seems like it's extremely difficult to avoid repeating work currently +because patches have been made but the cvs version hasn't changed. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Dillo Weekly News + +From: Allan Clark - 2000-10-15 11:43 + +This weeks Dillo Weekly News has been posted you can find it here +http://www.shark.pwp.blueyonder.co.uk/news/news151000.html + +Allan Clark +allan@al... +shark@bl... + + + +Re: [Dillo-dev]Close Window command + +From: Sebastian Geerken - 2000-10-15 10:29 + +Livio Baldini Soares wrote: +> +> Hi all, +> +> messing with Dillo, I tried to do the `Close Window` function +> (Crtl-W or Menu select `File -> Close Window`), well nothing +> happenned. I looked at commands.c, and all I found was the empty stub: +> +> void a_Commands_close_callback(GtkWidget *widget, gpointer client_data) +> { +> } +> +> Below it I also saw the exit_callback and in it a commentary: +> /* There should be a close command that does this: */ +> /* gtk_widget_destroy (bw->main_window); */ +> +> So, that's exactly what I did, now close_callback looks like: +> +> void a_Commands_close_callback(GtkWidget *widget, gpointer client_data) +> { +> gtk_widget_destroy(((BrowserWindow *) client_data)->main_window); +> } +> +> What gives? Am I missing something? Why wasn't this already done? I +> tried it out and it's working fine. Including when your in the last +> window (only one left) and when you `close` it (not `exit`), dillo +> exits normally. +> +> I guess I've probably missed some previous discussion... Just in case, +> I'm sending the "patch". + +There is a function a_Interface_new_browser_window, so there should +probably also be a function a_Interface_destroy_browser_window, which +will do a bit more that destroying the widget. Merely destroying the +widget could even cause crashes (AFAIK dillo), since the still active +IO stuff could try to add text into the nonexisting page widget. + +Sebastian + + + +[Dillo-dev]About bugs #74 and #69 + +From: Livio Baldini Soares - 2000-10-15 08:49 + +Attachments: seg_fault.diff + +Hi (again), + +I know that Jorge is working on these bugs, but I *think* I've found +a good solution to the problems (actually I'm not really sure...). It +seems to me that the problem comes from a type of "concurrency" +problem within the IO and html/cache modules. The http requests in +Dillo, from what I understand, are all asynchronous, but I've seen no +concurrency controls in the modules. I think this lack of control is +generating the problem. + +For example, if I press the "Achieved Goals" link in Dillo's home +page, don't wait for it to load and press the "Changelog" link (or any +other, even the "Acheived Goals" repeatelly), Dillo will request ALL +the "clicked" links pages. Up to this part everything should be ok +(actually no, but I'll get to that later), the problem comes in when +the requests arrive. Many requests start coming in and Dillo gets +"confused" and can't handle them all. + +What I've done is prevented various (root) Url requests at the same +time. This is what Netscape does, when you click a link on a page, the +cursos turns into a watch and all the other links become +"un-clickable" until the new page gets loaded. I think this is a +"correct" behaviour and not a restriction to the user. + +I did this in Dillo by placing a type of LOCK in the BrowserWindow +(browser.h) structure. Its a gboolean `nav_lock`. When someone tries +to load a root-url, by using the `a_Nav_push` I set the nav_lock to +TRUE. By doing this I disabled any type of user navigation. The only +two places where `nav_lock` comes FALSE again is by pressing STOP (in +the `a_Commands_stop_callback) and in the `a_Nav_expect_done` +function, because here we can assume that the root url has changed +(bw->nav_stack[nav_stack_ptr]) and therefore we can allow the user to +navigate savely again. + +When I got this working I would still (very seldomly) get +seg. faults. Studying the problem I found out that if, for example, +you click on a link, then wait until it get "unlocked" (when the +`a_expect_done` is called), then press BACK before the entire page +loaded (pics and all), a few pending requests for that page are still +coming in. With that in mind, I tought of two choices: + +1) Everytime the user requested for an URL, Dillo should cancel all +the pending requests for old URLs, so that the requests wouldn't +arrive later "unexpectedly". + +2) Don't cancel the requests since Dillo has already made then; I +think it would be a wast of data. Instead just ignore the few pending +requests. + +I chose option 2. I did this similar to what Sam Dennis did a while +ago (when he send the patch). From what I can see applying these two +ideas (the lock and Sam's patch) we have a pretty much clean fix to +the problem. Of course I could be wrong and missing the "root" of the +problem. Does anybody see any flaws in what I've described above? + +This lock system, if it's conceptually correct, should fix this +bug. But what I've implemented is NOT the complete lock system, it's +just a preview on how I tought to fix this problem. If you guys like +the idea, I'll have to finish up the exception handling (so if there's +an error while downloading a page, navigation doesn't become forever +disabled, erroneously locked). + +I'm sending the patch that should implement this fix, included is +Sam's patch (html_loading.diff) and the cache patch (cache_patch), so +there's no need to apply those patches, only this one. This patch +should be applyed against the CVS version. + +hope this helps, bye, + +-- +Livio + + + +[Dillo-dev]Close Window command + +From: Livio Baldini Soares - 2000-10-15 06:24 + +Hi all, + +messing with Dillo, I tried to do the `Close Window` function +(Crtl-W or Menu select `File -> Close Window`), well nothing +happenned. I looked at commands.c, and all I found was the empty stub: + +void a_Commands_close_callback(GtkWidget *widget, gpointer client_data) +{ +} + +Below it I also saw the exit_callback and in it a commentary: +/* There should be a close command that does this: */ +/* gtk_widget_destroy (bw->main_window); */ + +So, that's exactly what I did, now close_callback looks like: + +void a_Commands_close_callback(GtkWidget *widget, gpointer client_data) +{ +gtk_widget_destroy(((BrowserWindow *) client_data)->main_window); +} + +What gives? Am I missing something? Why wasn't this already done? I +tried it out and it's working fine. Including when your in the last +window (only one left) and when you `close` it (not `exit`), dillo +exits normally. + +I guess I've probably missed some previous discussion... Just in case, +I'm sending the "patch". + +bye, + +-- +Livio + +--- dillo.orig/src/commands.c Mon Aug 28 22:25:45 2000 ++++ dillo.my/src/commands.c Sun Oct 15 04:17:31 2000 +@@ -63,10 +63,11 @@ void a_Commands_prefs_callback(GtkWidget +} + +/* +- * ? ++ * Close only the selected Window +*/ +void a_Commands_close_callback(GtkWidget *widget, gpointer +client_data) +{ ++ gtk_widget_destroy(((BrowserWindow *) client_data)->main_window); +} + +/* + + + +Re: [Dillo-dev]Archiving patches + +From: Eric GAUDET - 2000-10-15 06:21 + +-- En reponse de "Re: [Dillo-dev]Archiving patches" de Livio Baldini Soares, le +15-Oct-2000 : +> +> With all these patches I'm starting to get a little confused... I'm +> trying to solve bug 74# (and others that arise due to the same +> problem), I believe I've found the problem and have a "clean"and +> simple fix, but I'm supposed to build it on top of what version? +> 0.2.4? CVS? CVS with all the patches applyed? +> + +You should not bother with published patches unless you want to test one (and +only one at time : it's very unlikely you can apply all without reworking most +of the diffs, which will be done by Jorge for next version) +You want to patch against v0.2.4, (or CVS version, which claims to be v0.2.5). +It's also possible you need/find handy to patch a patched version. If you don't +patch against vanilla v0.2.4, list all patches needed before yours. + +> I'm asking cause some of these changes will affect other code we +> build on top. Plus there seems to be a new Dw beeing made, and a +> testbed(?). +> + +We're not sure of what the new Dw will look like. Sebastian hasn't finished it +yet. + +> It would be really nice if we had an updated CVS version to patch +> to, or if someone (one of the olders guys with the project) released a +> 0.2.5 or 0.2.4-1 or something like that, with all the "pending" +> patches included, cause frankly it seems too confusing and I have no +> idea where to start programming so my works are all wastedøutdated. +> + +Only jorge can decide if a submitted patch will be included in the official +dillo version. It's not a good thing to have a fully patched version. For us +patchers, there's only one developper version, the lastest : 0.2.4. +CVS is to be considered experimental. + +> By the way, is the `Bug Track System` being used? More precisely is it +> valid and not outdated? +> + +The bug track system is the most up-to-date informations you'll have, because +it's automated and updated by everybody (actually I think Jorge is kind of +moderating it, but the delay is not noticably larger than one day). +Use it to report bugs you've found and things you want fixed by somebody else. +Use it to tell everybody what you are working on (to avoid duplicate efforts). + +----------------------------------- +Eric GAUDET +Le 15-Oct-2000 a 13:07:20 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Archiving patches + +From: Livio Baldini Soares - 2000-10-15 03:15 + +Allan Clark writes: +> Just to let everyone know I have started to archive most of the patches that +> get sent to the list, it was prompted by Sammy's post about looking for the +> first find text patch, anyway you can find a sort of index at +> http://www.shark.pwp.blueyonder.co.uk/patches.html I say sort of as it makes +> no attempt to explain the patches merely provides links to them. +> + +This is really helpfull! I got all the patches (ps. seems like +html_loading.diff and html_loading1.diff are the same. Anything wrong +with that?). + +With all these patches I'm starting to get a little confused... I'm +trying to solve bug 74# (and others that arise due to the same +problem), I believe I've found the problem and have a "clean"and +simple fix, but I'm supposed to build it on top of what version? +0.2.4? CVS? CVS with all the patches applyed? + +I'm asking cause some of these changes will affect other code we +build on top. Plus there seems to be a new Dw beeing made, and a +testbed(?). + +It would be really nice if we had an updated CVS version to patch +to, or if someone (one of the olders guys with the project) released a +0.2.5 or 0.2.4-1 or something like that, with all the "pending" +patches included, cause frankly it seems too confusing and I have no +idea where to start programming so my works are all wastedøutdated. + +Sorry if I seemed annoyed, but I'm not. It's just not nice to have +people's effort thrown away in vain, when they could be producing lots +if things were a little bit more organized. + +By the way, is the `Bug Track System` being used? More precisely is it +valid and not outdated? + +bye and sorry for bugging yall ;-) + +-- +Livio + + + +[Dillo-dev]Archiving patches + +From: Allan Clark - 2000-10-14 18:25 + +Just to let everyone know I have started to archive most of the patches that +get sent to the list, it was prompted by Sammy's post about looking for the +first find text patch, anyway you can find a sort of index at +http://www.shark.pwp.blueyonder.co.uk/patches.html I say sort of as it makes +no attempt to explain the patches merely provides links to them. + +Allan Clark +allan@al... +shark@bl... + + + +Re: [Dillo-dev]Bug #85 fix + +From: Daniel Roberts - 2000-10-14 18:20 + +--- Daniel Roberts wrote: + +> That's why one does QA/regression tests. :-) +> Perhaps this is a sign that Dillo needs some kind of +> QA/regression testing framework? + +BTW, this also is reason to think about open-source +philosophy... I am not ordinarily that philosophical, +but it has occured to me that ESR said in "The +Cathedral and the Bazaar," that "given enough eyes, +all bugs are shallow." + +However, seeing this bug which has regressed THREE +times now, I think, proves ESR wrong on this point. +His approach seems rather like the classic "monkeys at +typewriters" approach to Shakespeare--that is, given +enough 1000's of monkeys at enough 1000's of +typewriters, one of them somewhere will type "to be or +not to be." + +I do believe however, this proves why one needs to +think of open-source as merely the LICENSING framework +for a project, and not a specification on how the +development efforts are coordinated and managed... +Case in point: the GCC Steering Committee does +automated regression tests. I think Dillo could +benefit from this, too. + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +Re: [Dillo-dev]Bug #85 fix + +From: Daniel Roberts - 2000-10-14 17:10 + +--- Sammy Mannaert wrote: + +> this is a bug i once fixed ... i know the bookmarks +> have been rewritten so the old mistake might have +> come back for the THIRD time :) (it was originally +in +> gzilla/armadillo, where i fixed it, then dillo came +> into existance, where i fixed it again (i think), +and +> now again) + +> any predictions on how much it will show up again ? + +That's why one does QA/regression tests. :-) Perhaps +this is a sign that Dillo needs some kind of +QA/regression testing framework? + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Messenger - Talk while you surf! It's FREE. +http://im.yahoo.com/ + + + +Re: [Dillo-dev]Bug #85 fix + +From: Eric GAUDET - 2000-10-14 15:42 + +-- En reponse de "Re: [Dillo-dev]Bug #85 fix" de Sammy Mannaert, le 14-Oct-2000 +> +> strange ... +> +> this is a bug i once fixed ... i know the bookmarks have been rewritten +> so the old mistake might have come back for the THIRD time :) (it was +> originally in gzilla/armadillo, where i fixed it, then dillo came into +> existance, where i fixed it again (i think), and now again) +> +> any predictions on how much it will show up again ? :) +> + +When the bookmark plugin I'm coding will be integrated, it won't anymore : +there will be *new* bugs ;-) + +> sammy +> +> PS: i've been pretty inactive lately (though i have been following the +> mailing list), i'll try doing a few patches in the coming month ... +> + +me too :-/ + +----------------------------------- +Eric GAUDET +Le 15-Oct-2000 a 00:39:28 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Bug #85 fix + +From: Sammy Mannaert - 2000-10-14 15:13 + +Livio Baldini Soares wrote: + +> Hi again, +> +> first let me thank Eric for taking the time in answering me. I found +> out what the problem was with my glib (I had 2 glib's installed, one +> in /usr/ and the other in /usr/local, I guess they were conflicting, +> since their versions didn't match). +> +> Messing around with Dillo I wanted to bookmark Dillo's home page +> (dillo.so....net) and then Seg. Fault! +> +> I looked at the code, and I guess I got a patch working (actually just +> an tiny change, just a NULL check). Latter I found out at the Bug +> Track page that this was bug #85. Hope this helps, here's the patch. +> +> bye, +> +> PS: I read in the mail archive that someone made a patch for the `Find +> Text...' function, where can I find it? The only thing I found was +> another patch to be used afterwards so the use of anchors wouldn't be +> needed. +> +> -- +> Livio +> +> $ diff -pru dillo/src/bookmark.c dillo.my/src/bookmark.c +> +> --- dillo/src/bookmark.c Mon Aug 28 22:43:47 2000 +> +++ dillo.my/src/bookmark.c Fri Oct 13 21:25:41 2000 +> @@ -165,7 +165,7 @@ void a_Bookmarks_add(GtkWidget *widget, +> return; +> +> /* If the page has no title, lets use the URL */ +> - if (strcmp (title, ¨) == 0) +> + if ( !title || (strcmp (title, ¨) == 0)) +> title = url; +> +> #ifdef TITLE39 +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +strange ... + +this is a bug i once fixed ... i know the bookmarks have been rewritten +so the old mistake might have come back for the THIRD time :) (it was +originally in gzilla/armadillo, where i fixed it, then dillo came into +existance, where i fixed it again (i think), and now again) + +any predictions on how much it will show up again ? :) + +sammy + +PS: i've been pretty inactive lately (though i have been following the +mailing list), i'll try doing a few patches in the coming month ... + + + +RE: [Dillo-dev]Bug #85 fix + +From: Allan Clark - 2000-10-14 08:47 + +You should find the original message in the archives here +http://www.geocrawler.com/lists/3/SourceForge/702/0/4469704/ +also I put it on the site I use for the dillo news although I don't link to +it, I do that with most of the pathces just for safe keeping you can find it +here +http://www.shark.pwp.blueyonder.co.uk/findtext.diff.gz + + +> PS: I read in the mail archive that someone made a patch for the `Find +> Text...' function, where can I find it? The only thing I found was +> another patch to be used afterwards so the use of anchors wouldn't be +> needed. + + + + +[Dillo-dev]Bug #85 fix + +From: Livio Baldini Soares - 2000-10-13 23:52 + +Hi again, + +first let me thank Eric for taking the time in answering me. I found +out what the problem was with my glib (I had 2 glib's installed, one +in /usr/ and the other in /usr/local, I guess they were conflicting, +since their versions didn't match). + +Messing around with Dillo I wanted to bookmark Dillo's home page +(dillo.so....net) and then Seg. Fault! + +I looked at the code, and I guess I got a patch working (actually just +an tiny change, just a NULL check). Latter I found out at the Bug +Track page that this was bug #85. Hope this helps, here's the patch. + +bye, + +PS: I read in the mail archive that someone made a patch for the `Find +Text...' function, where can I find it? The only thing I found was +another patch to be used afterwards so the use of anchors wouldn't be +needed. + +-- +Livio + +$ diff -pru dillo/src/bookmark.c dillo.my/src/bookmark.c + +--- dillo/src/bookmark.c Mon Aug 28 22:43:47 2000 ++++ dillo.my/src/bookmark.c Fri Oct 13 21:25:41 2000 +@@ -165,7 +165,7 @@ void a_Bookmarks_add(GtkWidget *widget, +return; + +/* If the page has no title, lets use the URL */ +- if (strcmp (title, ¨) == 0) ++ if ( !title || (strcmp (title, ¨) == 0)) +title = url; + +#ifdef TITLE39 + + + +RE: [Dillo-dev]Newbie questions + +From: Eric GAUDET - 2000-10-13 11:14 + +-- En reponse de "[Dillo-dev]Newbie questions" de Livio Baldini Soares, le +13-Oct-2000 : +> Hi guys, +> +> I was looking around in Sourceforge for a new browser in constrution +> (or finished), 'cause I'm goddam sick of Netscape exiting for no +> reason at all. I found that Dillo was the best project and looks like +> it has future. I liked the project so I've decided to try to +> contribute in any way way I can. The problem is I'm still a newbie in +> Linux and Unix programming, so if I'm being out of hand or something, +> please let me know. +> + +Welcome. + +> Where are the latest versions/patches? I saw somewhere on your webpage +> (dillo.so....net/Dname.html) that there are MIME/ and URL/ +> directories undeer the src/, but when I got the 0.2.4 version, I found +> no such directories. +> + +Lastest version is 0.2.4. You can patch against it. mime and url directories, +as well as the Dname.html page look like old stuff (gzilla era), you can safely +ignore them. + +> I downloaded the cvs files by doing: +> +> $ cvs -z3 -d:pserver:anonymous@cv...:/cvsroot/dillo co +> dillo +> +> like indicated on the Sourceforge CVS page. And then couldn't compile +> it. The problem was with the `g_print()'. I don't know, but there must +> be something wrong with my system (I use Debian 2.1, aka potato, and +> have installed: libglib1.2(-dev) -- 1.2.7-2). I try to compile a +> simple program like: +> +> ----------------------- +>#include +> +> int main(void){ +> +> g_print("Testing...\n"); +> +> return 0; +> } +> ----------------------- +> And compile it: +> $ gcc test.c -o test -lglib -I/usr/lib/glib/include/ +> $ ./test +> Segmentation fault +> + +Did you try to trace the program ? (I use xxgdb, which is an athena +front-end to gdb, crude but efficient : "xxgdb ./test", then run, then stack ) + +> Someone knows what's going on? +> +> What I did to "overcome" this problem is switched to plain `printf()' +> function: +> +> $ cd src/ +> $ for i in `find . -name "*.c"`; do ./chg $i g_print printf; done +> +> And THEN it compiled. I'm running it fine and enjoying it! Congrats on +> the great work guys. +> + +If you want your patches included in dillo, you'll have to fix this glib +problem. + +> PS: Sorry about the stupid questions, and the long mail. + +We're here to help, you can ask. + +> PS1: Sorry for the bad english..., I'm Brazilian. +> + +No problem : most of us are not native english speaker and we won't even notice +a thing ;-) + +----------------------------------- +Eric GAUDET +Le 13-Oct-2000 a 20:02:55 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Newbie questions + +From: Livio Baldini Soares - 2000-10-13 04:56 + +Hi guys, + +I was looking around in Sourceforge for a new browser in constrution +(or finished), 'cause I'm goddam sick of Netscape exiting for no +reason at all. I found that Dillo was the best project and looks like +it has future. I liked the project so I've decided to try to +contribute in any way way I can. The problem is I'm still a newbie in +Linux and Unix programming, so if I'm being out of hand or something, +please let me know. + +Where are the latest versions/patches? I saw somewhere on your webpage +(dillo.so....net/Dname.html) that there are MIME/ and URL/ +directories undeer the src/, but when I got the 0.2.4 version, I found +no such directories. + +I downloaded the cvs files by doing: + +$ cvs -z3 -d:pserver:anonymous@cv...:/cvsroot/dillo co dillo + +like indicated on the Sourceforge CVS page. And then couldn't compile +it. The problem was with the `g_print()'. I don't know, but there must +be something wrong with my system (I use Debian 2.1, aka potato, and +have installed: libglib1.2(-dev) -- 1.2.7-2). I try to compile a +simple program like: + +----------------------- +#include + +int main(void){ + +g_print("Testing...\n"); + +return 0; +} +----------------------- +And compile it: +$ gcc test.c -o test -lglib -I/usr/lib/glib/include/ +$ ./test +Segmentation fault + +Someone knows what's going on? + +What I did to "overcome" this problem is switched to plain `printf()' +function: + +$ cd src/ +$ for i in `find . -name "*.c"`; do ./chg $i g_print printf; done + +And THEN it compiled. I'm running it fine and enjoying it! Congrats on +the great work guys. + +PS: Sorry about the stupid questions, and the long mail. +PS1: Sorry for the bad english..., I'm Brazilian. + +thanks for the attention, + +-- +Livio + + + +[Dillo-dev]Patch to support font-loading on the iPaq handheld. + +From: Eric Christianson - 2000-10-12 17:15 + +This patch allows one of the default fonts on the compaq iPaq +linux distribution to work. (www.handhelds.org) + + +1098,1103d1097 +< +< if (font->font == NULL) { +< /* Can't load the font - try another platform font that should be available. (iPaq) */ +< font->font = gdk_font_load("-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1"); +< } +< + +Eric Christianson +RidgeRun, Inc. +http://www.ridgerun.com + + + +Re: [Dillo-dev]Find text patch + +From: Sebastian Geerken - 2000-10-11 20:03 + +Sam Dennis wrote: +> I did think of doing something like that, but I presumed that the functions +> already in place would have been exported if that was desirable. +I wrote all these functions (from +Dw_gtk_scroller_adjustment_value_changed to the end) for anchors, and +exported only those which were necessary for them. If some functions +are useful for other purposes, they may be exported, too. + +Sebastian + + + +Re: [Dillo-dev]Find text bugs + +From: Sam Dennis - 2000-10-10 17:24 + +On Tue, Oct 10, 2000 at 01:25:42AM +0000, Sam Dennis wrote: +> Er, it does segfault sometimes, I have to admit, but I'm almost certain that +> it's not my fault... + +I think that most of the crashes are happening in the html rendering, +actually. Although I have had one or two of them inside a perfectly valid +call to realloc. + +Since then I've tried to test it by searching around a nice long court +transcript and it didn't crash once. This and a number of other things makes +me begin to suspect my libc instead... + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Find text patch + +From: Sam Dennis - 2000-10-10 17:19 + +On Tue, Oct 10, 2000 at 04:43:17PM +0200, Sebastian Geerken wrote: +> Sam Dennis wrote: +> > +> > I've implemented a find text command for the first instance of the string +> > (it shouldn't be too difficult to extend it to finding multiple instances, +> > probably just starting by looking from the line after the last instance was +> > found). +> > +> > I'm sorry about the anchor, but it seemed like the only sane way to scroll +> > to the line we found. +> +> This patch doesn't use anchors. Apply it after Sam's patch. +> +> Sebastian + +I did think of doing something like that, but I presumed that the functions +already in place would have been exported if that was desirable. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Find text patch + +From: Sebastian Geerken - 2000-10-10 13:08 + +Attachments: findtext2.diff + +Sam Dennis wrote: +> +> I've implemented a find text command for the first instance of the string +> (it shouldn't be too difficult to extend it to finding multiple instances, +> probably just starting by looking from the line after the last instance was +> found). +> +> I'm sorry about the anchor, but it seemed like the only sane way to scroll +> to the line we found. + +This patch doesn't use anchors. Apply it after Sam's patch. + +Sebastian + + + +[Dillo-dev]Find text bugs + +From: Sam Dennis - 2000-10-10 00:22 + +Er, it does segfault sometimes, I have to admit, but I'm almost certain that +it's not my fault... + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Find text patch + +From: Sam Dennis - 2000-10-10 00:10 + +Attachments: findtext.diff.gz + +I've implemented a find text command for the first instance of the string +(it shouldn't be too difficult to extend it to finding multiple instances, +probably just starting by looking from the line after the last instance was +found). + +I'm sorry about the anchor, but it seemed like the only sane way to scroll +to the line we found. + +It doesn't highlight the string found in any way, partially because I don't +think that any mechanism for this is currently in place. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Find text implementation problems + +From: Sam Dennis - 2000-10-09 20:15 + +On Mon, Oct 09, 2000 at 10:54:32PM +0200, Sebastian Geerken wrote: +> ... +> scroller = GTK_DW_SCROLLER (bw->docwin); +> view = GTK_DW_VIEW (dw_scroller->viewport); +> border = (DwBorder*) (view->dw); +> page = (DwPage*) (border->child); + +Er, a little convoluted, isn't it? + +> +> I think border is sometimes NULL, so you may add some checks. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Find text implementation problems + +From: Sebastian Geerken - 2000-10-09 19:21 + +Sam Dennis wrote: +> +> I've been looking at implementing the find text function and had got half +> way through mentally coding a solution (because of the DwPage{Line,Word}) +> before I realised that all the callback has is the browser window, and I +> could see no way of getting at a DwPage from that, which is essential for +> searching. +> +> Am I missing something obvious? + +BrowserWindow *bw; +GtkDwScroller *scroller; +GtkDwView *view; +DwBorder *border; +DwPage *page; + +scroller = GTK_DW_SCROLLER (bw->docwin); +view = GTK_DW_VIEW (dw_scroller->viewport); +border = (DwBorder*) (view->dw); +page = (DwPage*) (border->child); + +I think border is sometimes NULL, so you may add some checks. + +Sebastian + + + +[Dillo-dev]Small idea for caching + +From: Sam Dennis - 2000-10-09 17:22 + +I've just discovered a note I made to myself a while ago about dillo's +caching system. There is currently a complex system of callbacks necessary, +but couldn't a lot of that be thrown away with a simple pipe between the +caching system (server) and the dillo widget (client)? + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Activity + +From: Jorge Arellano Cid - 2000-10-09 17:07 + +Hi there! + + +Just as before, silence periods on the mailing list, signal +high activity on the background! (Well, my email box seldom stops +its flow). + +I'm very pleased for the "parallel" working the code is getting +(Several improvement and fixing patches, design on the widget +side and design on the Networking and middle layers by my side). + +Currently I have a lengthy queue of patches waiting to be +processed (from Jörgen, Eric, Agustín, Marcos, ...). And I keep +trying to solve the design issues of Networking/Middle-Layers +that result in a lot of related bugs. I think this is the highest +priority (for me to work on); Look this: + +- BUGs 74, 84, 64 and 69 are related to it. +- File images being decoded every time (not fed by the dicache) +- Fine reload functionality can't be done without it. +- The problem asked by Sean MacLennan +- Sudden crashes +- Slow downloads (it may happen) +- General browser stability. +- etc. + +I'll keep working on it all October; If I don't succeed, I'll +start reviewing/integrating every patch and make a new release +based on 0.2.4. + +The good news is that finally I got into a design model that +handles all the necessary stuff. The bad new is that it's too +complex (and we all know that maintaining such things becomes a +nightmare). So, it will be done when I devise a way to simplify +it one or two "degrees". + + +Jorge.- + +Ps: Marcos has sent me a patch with basic authentication support! + +------------------------- ooOOoo ----------------------------- +Some answers: + +> I am try to add Mosaic style remote access to dillo. From a unix signal +> handler I want to push an url. The command a_Nav_push works *once*, then +> fails from then on. + +Yes, I know. That's the right way to do it though. +I mean: a_Nav_push should not crash; that's a BUG. + +> I have a patch below that shows a very simple +> example of this, plus an attempt to set the text in the location widget. +> I can set the text correctly, but I do not know how to then signal gtk +> to process the line. + +That is part of a_Nav_push's work. You should not worry doing +it "by hand". It seems to me that you'll have to wait until the +design concerns that eliminate "the BUG" are done. + +(The only thing you need to worry about is not calling +a_Nav_push from an interrupt handler, but to generate an event +that triggers it from GTK's main loop). + +------------------------------------- + +> I've been looking at implementing the find text function and had got half +> way through mentally coding a solution (because of the DwPage{Line,Word}) +> before I realised that all the callback has is the browser window, and I +> could see no way of getting at a DwPage from that, which is essential for +> searching. +> +> Am I missing something obvious? + +Obvious? I don't think so! + +The top 'dw' is set by a_Dw_gtk_scroller_set_dw (you can follow +the chain from there). + +In brief: + +bw->docwin is a GtkDwScroller +bw->docwin->viewport->dw is a DwBorder +bw->docwin->viewport->dw->child is a DwPage or a DwImage + +so, something like this will get you going: + +GtkDwScroller *scroller = bw->docwin; +DwBorder *border = scroller->viewport->dw; +DwPage *page = border->child; + +Notes: you have to add type checks and things like that. +I haven't tested this but it should be very close. + +Hope this helps. + + + +Re: [Dillo-dev]Find text implementation problems + +From: Sam Dennis - 2000-10-09 16:43 + +On Mon, Oct 09, 2000 at 10:26:07AM +0900, Eric GAUDET wrote: +> -- En reponse de "[Dillo-dev]Find text implementation problems" de Sam Dennis, +> le 08-Oct-2000 : +> > I've been looking at implementing the find text function and had got half +> > way through mentally coding a solution (because of the DwPage{Line,Word}) +> > before I realised that all the callback has is the browser window, and I +> > could see no way of getting at a DwPage from that, which is essential for +> > searching. +> > +> > Am I missing something obvious? +> > +> +> You'll have to create a new external function in DwPage (a_Dwpage_findtext ?). +> That way you can either register it as a callback, or call it yourself from +> whatever other source (command.c ?). +> + +Even if I do that, I still need a pointer to a DwPage, and I see no way of +getting it. There is also the issue of frames and (possibly) tables here, as +both are separate pages, how do we know which to search even if we can get +pointers to them? + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +RE: [Dillo-dev]Find text implementation problems + +From: Eric GAUDET - 2000-10-09 01:26 + +-- En reponse de "[Dillo-dev]Find text implementation problems" de Sam Dennis, +le 08-Oct-2000 : +> I've been looking at implementing the find text function and had got half +> way through mentally coding a solution (because of the DwPage{Line,Word}) +> before I realised that all the callback has is the browser window, and I +> could see no way of getting at a DwPage from that, which is essential for +> searching. +> +> Am I missing something obvious? +> + +You'll have to create a new external function in DwPage (a_Dwpage_findtext ?). +That way you can either register it as a callback, or call it yourself from +whatever other source (command.c ?). + +----------------------------------- +Eric GAUDET +Le 09-Oct-2000 a 10:23:31 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Find text implementation problems + +From: Sam Dennis - 2000-10-08 22:41 + +I've been looking at implementing the find text function and had got half +way through mentally coding a solution (because of the DwPage{Line,Word}) +before I realised that all the callback has is the browser window, and I +could see no way of getting at a DwPage from that, which is essential for +searching. + +Am I missing something obvious? + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Daniel Roberts - 2000-10-08 17:03 + +--- Sebastian Geerken wrote: +> DwPage doesn't bother about its parent widget +> (either at toplevel, or in a DwTable, or, as inline +> frame, in a DwPage?). It will just paint itself +where +> the parent wants it to do, and report size changes +> (incremental rendering!) to its parent. (BTW: Vice +> versa, DwTable will not bother about its children, +it +> only regards at them as DwWidget's.) + +This sounds like a VERY nice thing! I believe +Incremental reflow is what the Mozilla people call +this in Gecko, BTW. This should make Dillo better +than Netscape 4.x was at table rendering! Incidently, +Netscape's table rendering was VERY slow, inefficient, +and memory-hogging. It sized things dynamically +during multiple attempts, storing every attempt in +memory. This meant (if I understand them correctly) +that say, for tables of 10 columns by 10 rows, it +would store 100 attempted and failed trials in memory +before getting it right. Since Netscape never +implemented incremental layout of page sections, the +document state was split up and most of it used to +simulate a cell as a nested HTML document. This +allowed them to use the existing layout code to +simulate the layout of that cell multiple times until +the size was right. It was slow and wasteful of +memory. To make matters worse, their attempts to +optimize and streamline made the code difficult to +read and never really solved the problem of less than +optimal memory use and speed. + +For details, and mistakes to avoid that Netscape made, +I find this document VERY interesting reading: + +http://www.mozilla.org/classic/layodesc.html + +> This is very nice in Gtk+: all widgets have a very +> special purpose, a button is something where you can +> click on, but how it looks is determined by *its +> child*. You can even nest buttons, which is +> admittedly quite silly, but who knows. (In early +> versions of gnome, the panel menu entries had +> submenus on the right side.) This results sometimes +> in a horrible widget hierarchy, but is still +> efficient enough, and much easier to extend than if +> you have buttons with a label, buttons with a +pixmap, +> buttons with a pixmap and a label below the pixmap, +> buttons with a pixmap and a label right of the +pixmap +> etc. + +Interesting. So does this mean that you could have +say 3 distinct buttons inside each other, each +performing different actions, like so: + +------------------------ +| Button 1 | +| | +| |---------| |------| | +| |Button 2 | |Btn. 3| | +| | | | | | +| ----------- -------- | +| | +------------------------ + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Sebastian Geerken - 2000-10-08 15:03 + +Eric GAUDET wrote: +> > As I say, I'll need to learn from the ground up on more basic +> > things first, however. :-) But I do want to see what I can do. +> > +> +> What I did for that is choose easy bugs in the bug-track engine (or some of my +> own ideas) and try to make a patch, as a skill training. You'll find most of +> the code clean and easy to understand. Some areas are still obscure to me +> (attrs ? cache ?). Even if the patches are rejected, this is still a great way +> to learn before trying hardcore table/frame coding ;-). +> May I suggest : +> - PNG transparency (bug #60) +> - GIF animations support +> - form widget jumping with tab/shift+tab (bug #86) + +This depends heavily on the Dw structure (in both cases, either if you +let Gtk+ (GtkWindow) do the work, or -- which I would prefer -- let it +do by GtkDwViewport). + +> - X clipboard support (bug #59) +> - adding "copy this link" to the popup menu +> - adding "save this image" to the popup menu +> - fix the status bar informations disapearing +> - implement "find text" +> - implement basic httpauth (see with Sean if he's not doing it already) +> - implement SUP and SUB tags +> - fix corrupted PNG segfault. + +Or: +- When jumping to an #anchor in the same page, the url should be +pushed on the navigation stack. See Nav_open_url and struct +_BrowserWindow. +- A menu of the last visited urls, like the one you get when you hold +the "Back" button pressed for a while in Netscape, or click on the +small button right on the "Back" button in MSIE. +- Implement the tag, and e.g. add an menu "Related pages" or +so, with some accelerators, so the user must only press N for the next +page etc. (I hope, some authors still use this tag.) + +Sebastian + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Sebastian Geerken - 2000-10-08 15:03 + +Eric GAUDET wrote: +> I'm thinking of 3 reasons why table and frames are different. +> [...] + +4) Tables are 2-dimensional, while frames are only aligned in one +direction, i.e. you must nest framesets to get a grid of frames. + +5) The size of a table cell is (in most cases) calculated by the +browser, the frame's size is determined by the web author. + +> [...] +> Perhaps we can come with a common page structure (ex DwPage ?), that would have +> the ability to be both a full html page (part of a frameset) or a table cell. + +DwPage doesn't bother about its parent widget (either at toplevel, or +in a DwTable, or, as inline frame, in a DwPage?). It will just paint +itself where the parent wants it to do, and report size changes +(incremental rendering!) to its parent. (BTW: Vice versa, DwTable will +not bother about its children, it only regards at them as DwWidget's.) +This is very nice in Gtk+: all widgets have a very special purpose, a +button is something where you can click on, but how it looks is +determined by *its child*. You can even nest buttons, which is +admittedly quite silly, but who knows. (In early versions of gnome, +the panel menu entries had submenus on the right side.) This results +sometimes in a horrible widget hierarchy, but is still efficient +enough, and much easier to extend than if you have buttons with a +label, buttons with a pixmap, buttons with a pixmap and a label below +the pixmap, buttons with a pixmap and a label right of the pixmap etc. + +> I'm not sure this will be the best way : most table cells contain only an image +> or a text paragraph. Building a whole html page for that will be a big waste +> (think about those >1000k tables ;-). + +(gdb) print sizeof (DwPage) +$1 = 184 + +(I admit that it will take a bit more after initialization.) + +Memory is not the problem, but perhaps time, since size negotiation +could happen to often. But currently it works very fast for normal +pages, and so I think we should look how it will work for tables, and +then eventually optimize it in detail. + +> I'd prefer to split the current DwPage in two widgets : one for the html +> rendering only (say DwRenderedHtml) which would do what the current DwPage do +> with lines, words ; one just like DwPage, but without what's done by +> DwRender : only links, gc, attrs, anchors, ... This DwPage would of course +> point to a DwRenderedHtml + +I'll bother about this, when Dw is complete. ;-) + +Sebastian + + + +[Dillo-dev]Dillo News + +From: Allan Clark - 2000-10-08 14:36 + +Hi all, the Dillo Weekly News is up and the url is +http://www.shark.pwp.blueyonder.co.uk/news081000.html + +Allan Clark +allan@al... +shark@bl... + + + +[Dillo-dev]Minor view source change + +From: Sam Dennis - 2000-10-08 13:27 + +Attachments: viewsource.diff + +View source shouldn't get the url from the location widget as that isn't +necessarily the url of the page that is shown. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Eric GAUDET - 2000-10-08 06:52 + +-- En reponse de "Re: [Dillo-dev]RE: table/frames (was:What can I do?)" de +Daniel Roberts, le 08-Oct-2000 : +>> To make frames look like this, you'll have to do +>> much more complicated things. +> +> Ah, but what about inline frames? +> + +right, iframes are like a single table cell embeding a separate page (URL). No +span tough. And you still can show the same structure as a complex table with +it. +It's kind of new too (HTML4 ?) : even my nestcape 4.72 can't render them. +Anyway, all suggestions I heard about table/frames handling can quite easily be +extended to iframe (once we've decided how to embed a page in a page). +Not a big deal. + +> +> All in all, it looks to me like tables/frames are THE +> next big thing to concentrate on in Dillo. + +Right again ! + +> As I say, I'll need to learn from the ground up on more basic +> things first, however. :-) But I do want to see what I can do. +> + +What I did for that is choose easy bugs in the bug-track engine (or some of my +own ideas) and try to make a patch, as a skill training. You'll find most of +the code clean and easy to understand. Some areas are still obscure to me +(attrs ? cache ?). Even if the patches are rejected, this is still a great way +to learn before trying hardcore table/frame coding ;-). +May I suggest : +- PNG transparency (bug #60) +- GIF animations support +- form widget jumping with tab/shift+tab (bug #86) +- X clipboard support (bug #59) +- adding "copy this link" to the popup menu +- adding "save this image" to the popup menu +- fix the status bar informations disapearing +- implement "find text" +- implement basic httpauth (see with Sean if he's not doing it already) +- implement SUP and SUB tags +- fix corrupted PNG segfault. + +As you can see, there's some big code planned (table/frames, IO engine, +unified alignment), but there's also a lot of small things to do you can +choose to improve both your skills and dillo :-) + +> BTW, I am also curious now about cross-platform +> plans... Is the plan just to support Unices, or +> others like BeOS, Mac, or Windows? I am thinking +> since it is GTK+-based, Unices would be relatively +> easy... Windows support could be added too, since +> GTK+ supports Windows, but I can see a new +> networking/IO layer being needed... Same for BeOS, +> since GTK+ supports BeOS, too. Mac I would think +> would be even harder though. +> + +AFAIR there was a big effort to make dillo compile under libc5, and I heard +somebody tryied it on BSD with some success (a little less stable than on +linux ?). +I don't know about windos and beos, but I'm sure the folks here would welcome +any volunteer. + +----------------------------------- +Eric GAUDET +Le 08-Oct-2000 a 15:02:53 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]RE: table/frames (was:What can I do?) + +From: Daniel Roberts - 2000-10-08 04:54 + +--- Eric GAUDET wrote: + +> I'm thinking of 3 reasons why table and frames are +> different. + +These all do seem like valid reasons, too. + +> To make frames look like this, you'll have to do +> much more complicated things. + +Ah, but what about inline frames? + + +All in all, it looks to me like tables/frames are THE +next big thing to concentrate on in Dillo. As I say, +I'll need to learn from the ground up on more basic +things first, however. :-) But I do want to see what +I can do. + +BTW, I am also curious now about cross-platform +plans... Is the plan just to support Unices, or +others like BeOS, Mac, or Windows? I am thinking +since it is GTK+-based, Unices would be relatively +easy... Windows support could be added too, since +GTK+ supports Windows, but I can see a new +networking/IO layer being needed... Same for BeOS, +since GTK+ supports BeOS, too. Mac I would think +would be even harder though. + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +[Dillo-dev]RE: table/frames (was:What can I do?) + +From: Eric GAUDET - 2000-10-08 02:31 + +-- En reponse de "RE: [Dillo-dev]What can I do?" de Allan Clark, le 07-Oct-2000 +: +> +>> How are tables that different? Netscape/Mozilla used +>> to render tables as complete HTML documents within a +>> larger one. After all, tables can also have images, +>> text, and everything else a complete HTML document +>> has. +> That's the exact point that I made, I don't see how tables and frames are +> really any different. + +I'm thinking of 3 reasons why table and frames are different. + +1) Table cell can span on several row or colomns, frames don't. +Example : + + + + +
ab
cd
efg
+should be rendered like : ++---+-------+ +| | b | +| a +---+---+ +| | c | d | ++---+---+---+ +| e | f | g | ++---+---+---+ +To make frames look like this, you'll have to do much more complicated things. + +2) Frames can have sliders and be resized, tables don't. + +3) Table cells embedding an htlm page is only a convenient way of +rendering tables, but there is no actual html page (eg: file) as such. +Framesets _are_ separate html (or not) pages (in the cache) that have to be +loaded. + +That's why frames are not a subset of tables, and tables are not a subset of +frame. + +IMHO frames and table have a very different behavior, both the way they look +and their underlying implementation. +Perhaps we can come with a common page structure (ex DwPage ?), that would have +the ability to be both a full html page (part of a frameset) or a table cell. +I'm not sure this will be the best way : most table cells contain only an image +or a text paragraph. Building a whole html page for that will be a big waste +(think about those >1000k tables ;-). + +I'd prefer to split the current DwPage in two widgets : one for the html +rendering only (say DwRenderedHtml) which would do what the current DwPage do +with lines, words ; one just like DwPage, but without what's done by +DwRender : only links, gc, attrs, anchors, ... This DwPage would of course +point to a DwRenderedHtml + +For frames, we use GtkContainers with DwPages. + +For tables, a new widget DwTable would contain the structure of the table and +pointers to DwRenderedHtml widgets, one for each cell. +DwTable would be a word widget, just like an image is now. + +... that's it ;-) + +(and we should wait for Sebastian's new Dw widgets) + +----------------------------------- +Eric GAUDET +Le 08-Oct-2000 a 11:00:26 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]What can I do? + +From: Allan Clark - 2000-10-07 21:24 + + +> How are tables that different? Netscape/Mozilla used +> to render tables as complete HTML documents within a +> larger one. After all, tables can also have images, +> text, and everything else a complete HTML document +> has. +That's the exact point that I made, I don't see how tables and frames are +really any different. + + + +Re: [Dillo-dev]What can I do? + +From: Daniel Roberts - 2000-10-07 21:15 + +--- Sebastian Geerken wrote: + +> Gzw was written (afaik) mainly because of the size +> limitation for X windows (and so Gtk+ widgets), +> otherwise pure Gtk+ widgets could be used. It can +> embed Gtk+ widgets, but that does not work +perfectly, +> so there had been some discussion on eleminating Dw, +> but that will make dealing with the size limitation +> quite complicated. (This is my personal opinion. +> Jorge did not decide yet, what will be used in +> future, so I tried to implement and test my ideas.) + +Mozilla faced the same problem, both in the Motif and +the GTK+ ports. They ended up using a GTKLayout +widget instead of a GTKDrawingArea for the page layout +area, IIRC. Problem with this however, was that they +then had a constant battle to fight with the GTKLayout +widget's want to do its own layout things... So they +wrote this whole new library/widget (with the help of +Owen Tayler of GTK+ fame) set called GTKSuperWin. +Could we perhaps use this, BTW? + +> Dw embeds Dw already now, e.g. bullets and images +> are Dw widgets embedded in a DwPage. Embedding a +> DwPage in a DwPage is also possible, and if they +> share the same html document (as in tables), the +html +> parser has to be extended, e.g . by a stack. I did +> already hack something like that which worked +> halfway, it should not be too hard. + +Sounds good. + +> Tables and frames are quite different, the only +> thing they have in common is, that they contain +text, +> so IMO the simplest way should be to write them as +> containers for pages. + +How are tables that different? Netscape/Mozilla used +to render tables as complete HTML documents within a +larger one. After all, tables can also have images, +text, and everything else a complete HTML document +has. + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +Re: [Dillo-dev]What can I do? + +From: Sebastian Geerken - 2000-10-07 12:01 + +Daniel Roberts wrote: +> Okay. Well, for starters, does the UI need anything? +> I'd like to experiment with GTK+ a bit if I can... I +> am trying to learn GTK+, so if anyone can give some +> pointers on using it (other than the tutorial, which I +> am already actively reading), I would appreciate it. +> Translation: I might need to ask lots of questions, if +> nobody minds. (Boy I wish a class were taught on GTK+ +> somewhere.) + +There is also a reference and some mailing lists at http://www.gtk.org. A +good "tutorial" for using Gtk+ are the sources of Gimp, a good way of +learning how to write new widgets is reading the sources of Gtk+ +itself. + +Sebastian + + + +Re: [Dillo-dev]What can I do? + +From: Sebastian Geerken - 2000-10-07 12:01 + +Hi, + +Daniel Roberts wrote: +> It is also interesting that dw (formerly gzw, I +> assume) is being re-writeen from scratch. Seems like +> this is rather what Mozilla did with Gecko. + +Dw is not completely rewritten, since the other widgets (mainly +DwPage) will ported to the new Dw. + +Gzw was written (afaik) mainly because of the size limitation for X +windows (and so Gtk+ widgets), otherwise pure Gtk+ widgets could be +used. It can embed Gtk+ widgets, but that does not work perfectly, so +there had been some discussion on eleminating Dw, but that will make +dealing with the size limitation quite complicated. (This is my +personal opinion. Jorge did not decide yet, what will be used in +future, so I tried to implement and test my ideas.) + +> As to tables/frames, how is it going to be done? I +> recall some discussions with Armadillo about possibly +> doing it by embedding dw within dw. Tables are +> admittedly a little bit different from frames, but I +> do think they are almost like flip sides of the same +> coin. + +Dw embeds Dw already now, e.g. bullets and images are Dw widgets +embedded in a DwPage. Embedding a DwPage in a DwPage is also possible, +and if they share the same html document (as in tables), the html +parser has to be extended, e.g . by a stack. I did already hack +something like that which worked halfway, it should not be too hard. + +Tables and frames are quite different, the only thing they have in +common is, that they contain text, so IMO the simplest way should be +to write them as containers for pages. + +Sebastian + + + +RE: [Dillo-dev]What can I do? + +From: Daniel Roberts - 2000-10-06 19:44 + +--- Allan Clark wrote: + +> Glad to hear from you, the above is kind of the +> implementation I had in mind for tables and frames, +> my suggestion is that we should have a page being +> either a list of horizontal subpages, a list of +> vertical subpages or a page as they are just now +> implemented with lines, and then each "leaf" page +can +> take care of drawing (alignment etc) by itself and +> all the parent pages need to do is tell all their +> children to re-draw, re-size etc. + +Interesting. But where I can see this getting tricky +is things like tables nested within tables, or with +things like inline frames (not to mention re-sizable +frames). How will this scheme handle those things? +For huge tables (like >1000k), won't it get a little +slow? Yes, there ARE tables >1000k. Mozilla had a +bug filed on such tables being slow to render. :-) + +> As for what you can do, well pick something you +> think dillo needs and just do it (I hope I won't get +> into trouble for nicking nike's slogan) I think +> the main thing is to get Sebastians port of dw +> working correctly, so if you can help with that it +> would be great but it is your time so do whatever +you +> enjoy the most. + +Okay. Well, for starters, does the UI need anything? +I'd like to experiment with GTK+ a bit if I can... I +am trying to learn GTK+, so if anyone can give some +pointers on using it (other than the tutorial, which I +am already actively reading), I would appreciate it. +Translation: I might need to ask lots of questions, if +nobody minds. (Boy I wish a class were taught on GTK+ +somewhere.) + + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +RE: [Dillo-dev]What can I do? + +From: Allan Clark - 2000-10-06 15:42 + +> Hello all! + + +> As to tables/frames, how is it going to be done? I +> recall some discussions with Armadillo about possibly +> doing it by embedding dw within dw. Tables are +> admittedly a little bit different from frames, but I +> do think they are almost like flip sides of the same +> coin. +> + +Glad to hear from you, the above is kind of the implementation I had in mind +for tables and frames, my suggestion is that we should have a page being +either a list of horizontal subpages, a list of vertical subpages or a page +as they are just now implemented with lines, and then each "leaf" page can +take care of drawing (alignment etc) by itself and all the parent pages need +to do is tell all their children to re-draw, re-size etc. +As for what you can do, well pick something you think dillo needs and just +do it (I hope I won't get into trouble for nicking nike's slogan) I think +the main thing is to get Sebastians port of dw working correctly, so if you +can help with that it would be great but it is your time so do whatever you +enjoy the most. + +Note to Sebastian: would you like me to put up the sources of your dw on the +web page I'm using to do the dillo news, that way you wouldn't have to mail +it to everyone who asks? I can also update it pretty much when needed. + + + +[Dillo-dev]What can I do? + +From: Daniel Roberts - 2000-10-06 15:26 + +Hello all! + +I am checking this out because Christopher Reid Palmer +has effectively admitted that Dillo will probably +become the real successor to Armadillo, and that +Armadillo is effectively dead, since he hasn't enough +time to dedicate to it. + +Dillo, IMHO, has definitely already surpassed both of +its predecessors (Gzilla and Armadillo) in almost +every aspect. I am hoping it is well on its way to +competing with the likes of KDE's Konquerer, or maybe +even Mozilla. Lord knows I worked on Mozilla for +quite a while (and still use it for everyday browsing, +cause there ain't any real alternative for GNOME folks +like me), but I still find Mozilla to be painfully +bloated, inefficient, slow, and memory-hogging, even +after their wonderful ground-up re-write based on +Gecko. Bottom line is, I have come to the same +conclusion that JWZ did--that is, all the open source +in the world cannot save Mozilla at this point. +Mozilla is pretty much hopeless. + +I think Mozilla's biggest problem was XUL. After +having seen what a cross-platform front-end interface +like Mozilla's XUL could be like, I am now convinced +that a native GTK+ interface would definitely be the +way to go. XUL is too bloated and far to slow for my +tastes. + +Anyway, I am happy to see some progress being made on +Dillo, and what's more, in the areas that really need +it the most, like Networking, I/O, and implementing +tables/frames. + +It is also interesting that dw (formerly gzw, I +assume) is being re-writeen from scratch. Seems like +this is rather what Mozilla did with Gecko. + +As to tables/frames, how is it going to be done? I +recall some discussions with Armadillo about possibly +doing it by embedding dw within dw. Tables are +admittedly a little bit different from frames, but I +do think they are almost like flip sides of the same +coin. + +Anyway, I unfortunately don't know too much about +Dillo internals, C/C++, or GTK+. So would somebody +like to point me to something I can do to help with +Dillo? I'd like to help if I can. + +===== +Is your JavaScript ready for Nav5 and IE5? +Get the latest JavaScript client sniffer at +http://developer.netscape.com/docs/examples/javascript/browser_type.html + +Sincerely, +Daniel +e-mail: zuperdee@pe... + +__________________________________________________ +Do You Yahoo!? +Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! +http://photos.yahoo.com/ + + + +[Dillo-dev]New Dw + +From: Sebastian Geerken - 2000-10-06 13:53 + +Hi! + +I've been working on a new Dw, mainly written from scratch. I've given +up the idea of making all elements GtkWidget's, since any attempt to +work around the window size limit would be far to complicated, but +designed and begun to implement a new Dw, which mainly follows the +goal to be more similar to Gtk, because (i) the design of Gtk+ is +quite nice and proven to be usable, (ii) that will make embedding Gtk +widgets simpler, and (iii) it will be simpler to understand for +someone who knows Gtk. + +It's mainly a simple copy of the Gtk structures: there is a DwWidget +(sorry for the doubled "widget"), derived from GtkObject and with +similar methods as GtkWidget, a DwContainer, and structures like +DwRectangle, DwAllocation etc. with 32 bit sizes. Furthermore there is +a Gtk+ widget GtkDwViewport, which embeds a DwWidget (more directly +than the old GtkDwView), and is, from the view of Gtk+, parent of all +Gtk+ widgets that are embedded in the DwWidgets. DwContainers will +simply have to report all their children (DwWidget's as well as +GtkWidget's), and GtkDwViewport will recursively sort out the +GtkWidget's (by the GTK_IS_WIDGET macro), so implementing a +DwContainer is not more complicated than implementing a GtkContainer. + +Currently, there are still many bugs, especially severe expose +problems for embedded Gtk+ widgets, and DwWidget is still quite +incomplete. After fixing the most severe bugs, I'll try to integrate +the new Dw (which currently runs in a testbed) into dillo soon, trying +to complete it in dillo itself. There is already a halfway working +DwPage (a port of my Gtk+ port of the old DwPage, to the new Dw). + +I'll send the sources to anyone who is interested, and I would be glad +about help from someone else who knows Gtk+ good. + +Sebastian + + + +[Dillo-dev]remote url access + +From: Sean MacLennan - 2000-10-02 15:49 + +Attachments: out + +Hi, + +I am try to add Mosaic style remote access to dillo. From a unix signal +handler I want to push an url. The command a_Nav_push works *once*, then +fails from then on. I have a patch below that shows a very simple +example of this, plus an attempt to set the text in the location widget. +I can set the text correctly, but I do not know how to then signal gtk +to process the line. + +Any help at all would be appreciated, + +Sean + + + +[Dillo-dev]Dillo Weekly News + +From: Allan Clark - 2000-10-02 00:17 + +The latest weekly news has been posted, a little light on content this week +due to the lack of activity on the list and the fact that the first one was +a little late and hence this week's only has two days worth of news. +The url is +http://www.shark.pwp.blueyonder.co.uk/news021000.html +Allan Clark +allan@al... +shark@bl... + + diff --git a/old/oldmail/200011.txt b/old/oldmail/200011.txt new file mode 100644 index 0000000..d52880e --- /dev/null +++ b/old/oldmail/200011.txt @@ -0,0 +1,2106 @@ +RE: [Dillo-dev]Re: About bug #60 (transparency in PNG's) + +From: Eric GAUDET - 2000-11-29 10:46 + +-- En reponse de "[Dillo-dev]Re: About bug #60 (transparency in PNG's)" +de Livio Baldini Soares, le 29-Nov-2000 : +> Does anybody know a better/faster solution to turn an guint32 into +> to three int's representing red, green and blue parts of the color? +> The solution I've implemented doesn't look too good :-( +> Tomorrow, after getting some sleep I'll look up my algebra and see if +> I can do some decent bit manipulation instead of calling strtol(). If +> anyone has any ideas please send them in. +> + +IMHO there's several problem with your calculations : + +1) the strol part is very inefficient, but that's not a real problem +because this code is _outside_ the loop. Anyway, here's how to do it : +(strip all the sprintf) +bg_blue = (prefs.bg_color0 & 0xFF; +bg_green = (prefs.bg_color>>8) & 0xFF; +bg_red = (prefs.bg_color>>16) & 0xFF; + +2) The loop is _always_ the sensible part ! You _never_ want to allocate +local variables like you did : +for (...) { +gint p,a; +(some compiler may optimize this, but you never know) +As a rule of thumb, it's better to allocate local variables at the +begining of a function. + +3) If you really want to improve speed, do all calculation only once in +local variables : i*3 is computed three times, it would be better to +have calculated i3 = i*3 and use i3. (same with i*4 used twice). +You could also have done i3 += 3 each loop, but on pentium-generation +cpu (whatever the brand, ppc, arm, ...) multiplications and additions +cost the same so it doesn't matter, and using i*3 is often more +readable and more robust (not sensible to initiallisation). + +4) Even better : look into a table is a calculation. png->linebuf[3*i] +is actually *(png + linebuf + 3*i). +You could have declared +guchar *pl = png->linebuf; +and in the loop : +if (!a){ +*(pl++) = bg_red; +*(pl++) = bg_green; +*(pl++) = bg_blue; +} + +The else part is basically the same, if a little more trickier, and you +can get rid of the costy for() : I let it to you as an exercise ;-) +(hint : row_num*png->rowbytes is ugly) + +5) Last : if(!a) is more complex than if(a) : invert the if/else. + +Hope this helps. + +So long Livio :-) + +----------------------------------- +Eric GAUDET +Le 29-Nov-2000 a 19:19:52 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Re: About bug #60 (transparency in PNG's) (sending patch) + +From: Livio Baldini Soares - 2000-11-29 03:36 + +Attachments: png_transparent.diff + +Sebastian Geerken writes: +> Livio Baldini Soares writes: +> > Hi all, +> > +> > I've been looking into the PNG transparency bug (#60). + + +Ok, so I got a working patch that gets the user preference bg_color +and sets that as transparent. Since it might take a while before +`a_Dw_widget_get_bg_color` or mask clipping gets done, this might be a +good thing to put it for now. The only thing is that this patch didn't +turn out as good as I'd like it to be... + +Does anybody know a better/faster solution to turn an guint32 into +to three int's representing red, green and blue parts of the color? +The solution I've implemented doesn't look too good :-( +Tomorrow, after getting some sleep I'll look up my algebra and see if +I can do some decent bit manipulation instead of calling strtol(). If +anyone has any ideas please send them in. + +I'm sending the patch as an attachment and should be applyied +against src/png.c from CVS. + + +bye all, best regards, + +-- +Livio + + + +Re: [Dillo-dev]Still some problems with the bugtrack engine + +From: Eric GAUDET - 2000-11-29 01:37 + +-- En reponse de "Re: [Dillo-dev]Still some problems with the bugtrack +engine" de Livio Baldini Soares, le 28-Nov-2000 : +> Hi Eric, how you doing? +> + +Hi Livio, nice to see you again in the list (I was afraid you left ;-) + +> Eric GAUDET writes: +>> I have Internal Server errors every time I try. +>> +> +> I added the bug for you. It's bug number *102*, check out the +> bug-track. I think that the problem appears when you leave out one of +> the fields in blank. I was getting an Internal Error too, but had +> left +> in blank the HTReproduce. When I filled it in with `Nothing`, the bug +> was submitted. +> + +Hmmm... I just tried it and I think you're right. + +Thanks + +----------------------------------- +Eric GAUDET +Le 29-Nov-2000 a 10:34:35 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]About bug #60 (transparency in PNG's) + +From: Sebastian Geerken - 2000-11-28 22:11 + +Livio Baldini Soares writes: +> Hi all, +> +> I've been looking into the PNG transparency bug (#60). After an +> hour of searches along src/png.c and libpng-dev thinking that it was +> an initilization issue I found out it had nothing to do with +> that. Later I found out that the problem was in +> `Png_datarow_callback`, in the `case 4:` the alpha channel wasn't +> being activated (there was even a `todo`, which I missed!). I've made +> a sketch that works, but I've come to a problem: +> +> Where do I find the current window (page) background color? + +Better: the background color of the parent of the image widget. This +will be different from the page background color, when tables are +implemented. + +> I guess +> this is the same problem with GIF transparency. When you have a +> transparent GIF and open it with the standard dillorc file, it'll look +> alright, but if you change the bg_color in your dillorc then the GIF +> will have in the transparent pixels NOT your background color, but the +> color for the standard bg_color that was in the original dillorc... +> +> So I guess that's a problem with GIF's and PNG's. Sebastian, is this +> bg_color integrated to the new Dw your making up? Should I wait for it +> to sent in the patch for PNG transparency, or should I make it +> already? (Actually, it's already done and working, but I didn't want +> to sent it in with this background color issue). + +I haven't done much on colors yet, currently there is only a function +a_Dw_widget_set_bg_color (which does nothing, but will soon work for +top-level widgets), and there will probably (when needed) a function +a_Dw_widget_get_bg_color (I'd prefer a function instead of a direct +access on structure members). Meanwhile, you may use dummy function +with that name (returning DW_PAINT_DEFAULT_BGND or so). + +However, I already suggested to Jorge to use clipping masks instead +of the parent's background color, since the latter would cause +problems with background images (this could be solved, but only +complicated and slow). Real alpha (more than 1 bit depth), as +supported by pgn (afaik) is not supported by X, but may be +implemented by dithered clipping masks (will look a bit ugly, but I +did never see a png in a web page which uses this feature). + +Sebastian + + + +Re: [Dillo-dev]Still some problems with the bugtrack engine + +From: Livio Baldini Soares - 2000-11-28 21:10 + +Hi Eric, how you doing? + +Eric GAUDET writes: +> I have Internal Server errors every time I try. +> +> I wanted to make this entry : +> - There's no "Copy Link Location" being worked by "egaudet@fr... +> 100%" +> +> :-/ + +I added the bug for you. It's bug number *102*, check out the +bug-track. I think that the problem appears when you leave out one of +the fields in blank. I was getting an Internal Error too, but had left +in blank the HTReproduce. When I filled it in with `Nothing`, the bug +was submitted. + +Jorge are you the one who take cares of the dillo's bug-track CGI's? +Could it be that in Dillo_insert.cgi a blank field could cause an +error? Maybe it should be tuned for errors and such, and give a +warning like: "X field left in blank, please fill it in..."... Just a +guess. + +best regards to all, + +-- +Livio + + + +[Dillo-dev]Still some problems with the bugtrack engine + +From: Eric GAUDET - 2000-11-28 16:40 + +I have Internal Server errors every time I try. + +I wanted to make this entry : +- There's no "Copy Link Location" being worked by "egaudet@fr... +100%" + +:-/ + +----------------------------------- +Eric GAUDET +Le 29-Nov-2000 a 01:38:01 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]About bug #60 (transparency in PNG's) + +From: Livio Baldini Soares - 2000-11-28 15:59 + +Hi all, + +I've been looking into the PNG transparency bug (#60). After an +hour of searches along src/png.c and libpng-dev thinking that it was +an initilization issue I found out it had nothing to do with +that. Later I found out that the problem was in +`Png_datarow_callback`, in the `case 4:` the alpha channel wasn't +being activated (there was even a `todo`, which I missed!). I've made +a sketch that works, but I've come to a problem: + +Where do I find the current window (page) background color? I guess +this is the same problem with GIF transparency. When you have a +transparent GIF and open it with the standard dillorc file, it'll look +alright, but if you change the bg_color in your dillorc then the GIF +will have in the transparent pixels NOT your background color, but the +color for the standard bg_color that was in the original dillorc... + +So I guess that's a problem with GIF's and PNG's. Sebastian, is this +bg_color integrated to the new Dw your making up? Should I wait for it +to sent in the patch for PNG transparency, or should I make it +already? (Actually, it's already done and working, but I didn't want +to sent it in with this background color issue). + +best regards to all, + +-- +Livio + + + +Re: [Dillo-dev]Misc. + +From: Livio Baldini Soares - 2000-11-28 13:34 + +Hi again, + + +I forgot something important, read below. + +Livio Baldini Soares writes: +> Hi again, +> +> think I fixed bug 100 already, read below. +> +> Livio Baldini Soares writes: +> +> > +> > > - There's a small bug within a_Url_squeeze. When there're too +> > > much "/.." sequences in the URL, it removes the server! +> +> +> I got to it, and I think I fixed it ok. I thought the original code +> kind of confusing, but I've done little changes (3 lines). Basically +> here is my diff (against src/IO/Url.c from CVS, but I think 0.3.0 will +> be ok too since this hasn't changed, I think): + + + +The a_Url_squeeze seems to work fine, but that never gets called for +user typed URL's. Im my opinion this is wrong, so I have another patch +which changes a_Nav_push to change the user specified URL to the +squeezed one. Then you'll be able to see how the a_Url_squeeze changes +the URL (using the previous patch I sent). Here is the patch against +src/nav.c, I changed only the a_Nav_push funtion: + +***************************************************** +--- dillo/src/nav.c Mon Nov 13 10:01:55 2000 ++++ dillo.new/src/nav.c Tue Nov 28 10:38:20 2000 +@@ -203,20 +203,22 @@ void a_Nav_remove_top_url(BrowserWindow +*/ +void a_Nav_push(BrowserWindow *bw, const char *Url) +{ +- char *p, *url; ++ char *p, *url, *sUrl; + +g_return_if_fail (bw != NULL); + +- url = g_strdup(Url); ++ sUrl = a_Url_squeeze(g_strdup(Url)); /* get the squeezed Url */ ++ url = g_strdup(sUrl); +if ( (p = strstr(url, "?!POST")) != NULL ) +*p = '\0'; + +a_Nav_cancel_expect(bw); +- bw->nav_expect.url = g_strdup(url); ++ bw->nav_expect.url = g_strdup(sUrl); +bw->nav_expect.title = NULL; +bw->nav_expecting = TRUE; +- Nav_open_url(bw, Url, FALSE); ++ Nav_open_url(bw, sUrl, FALSE); +g_free(url); ++ g_free(sUrl); +} + +/* +**************************************** + + +that's all, bye, + +-- +Livio + + + +Re: [Dillo-dev]Misc. + +From: Livio Baldini Soares - 2000-11-28 11:13 + +Hi again, + +think I fixed bug 100 already, read below. + +Livio Baldini Soares writes: + +> +> > - There's a small bug within a_Url_squeeze. When there're too +> > much "/.." sequences in the URL, it removes the server! + + +I got to it, and I think I fixed it ok. I thought the original code +kind of confusing, but I've done little changes (3 lines). Basically +here is my diff (against src/IO/Url.c from CVS, but I think 0.3.0 will +be ok too since this hasn't changed, I think): + +************************************************************ +diff -pru dillo/src/IO/Url.c dillo.new/src/IO/Url.c +--- dillo/src/IO/Url.c Sat Nov 11 01:54:45 2000 ++++ dillo.new/src/IO/Url.c Mon Nov 27 23:43:33 2000 +@@ -252,7 +252,10 @@ char *a_Url_squeeze(char *str) +str[ni++] = s[i]; +if ( nc && ni ) +--ni; ++ nc = ni; +while ( ni && str[--ni] != '/'); ++ if (!ni || (!strncmp(str, ") && ni == 6)) ++ ni = nc+1; /* if we couldn't find a parent direcory, restore value */ +s = p = p + 3; +} else if ( p[2] == '/' || !p[2] ) { /* "/./" or "/." */ +nc = p - s; +@@ -264,6 +267,8 @@ char *a_Url_squeeze(char *str) +p += 2; +} +} ++ ++ if (ni && str[ni-1] == '/') ni--; +/* Append the rest of 'str' */ +if ( ni == 0 && !*s ) str[ni++] = '/'; +while ( (str[ni++] = *s++) ); +***************************************************** + +What I do is when trying to look for a parent directory, prevent it +from eating up the hostname. That is done in the `if` I inserted. If +the variable `ni` got back to the beginning of the hostname (==0) or +found a '/' expect it's the one from " then restore it's +value... Umm, guess I'm not very good at explaining this.. is any body +understanding what the hell am I saying? If anybody wants me to +explain this again, just ask, I won't complain! + +I'll change the status to 100% in the bug-track when I get back net +connection. Oh, and I'm NOT suppossed to put `done`, this is done by +Jorge when he inserts the patch in the code (IF we agree the code is +worth putting in), is this correct Jorge? + +Another thing, there was a comment in the header of a_Url_squeeze +made by Jorge, saying the he wasn't sure that it was necessary. Well I +checked APACHE and it's NOT necessary to squeeze the URL. I sent in a +request with a telnet to port 80, and sent an `GET /./FAQ/../ HTTP/1.0`, +and got the /index.html. Seems to work fine with both /../ and /./, +but I'm not sure if this is true to all HTTP servers. The only time +APACHE complains is when we send in a request for /FAQ/../../, APACHE +claims this is a BAD REQUEST, but the new a_Url_squeeze prevents +this. + +that's enough for now!, any doubts or flames, don't hesitate to +send, + +bye yall, + +-- +Livio + + + +RE: [Dillo-dev]Re: + +From: Eric GAUDET - 2000-11-28 08:48 + +-- En reponse de "[Dillo-dev]Re:" de Jorge Arellano Cid, le 27-Nov-2000 +: +>> A friend of mine as access to several sparc stations (both 32 and 64 +>> bits, under linux and solaris 8). I asked him to test Dillo. +> +> Thanks. +> Actually dillo works perfectly on a Sparc 32, but the Sparc 64 +> and Solaris architectures haven't been tested. I'll be expecting +> that info. +> + +Dillo has been successfully tested under : +- sparc 5 (32 bits) linux, glibc 2.1.3, gcc 2.95.3 +- sparc ultra 1 (64 bits kernel, 32 bits userspace) linux, glibc 2.1.3, +gcc 2.95.3 +- sparc ultra 10 (64 bits) solaris 8, gcc 2.95.2 + +No problem at all : just compile and run :-)))) + +----------------------------------- +Eric GAUDET +Le 28-Nov-2000 a 17:44:57 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Re: + +From: Jörgen Viksell - 2000-11-28 07:12 + +>GtkHSeparator doesn't seem to have all the features needed for painting +>a HR tag with attributes : no line thickness (-> no SIZE attribute), +>only 3d-rendering (-> no NOSHADE attribute). +>Will it be a problem ? + +If the new Dw handles GTK widget as GTK does itself (resizing and stuff) +then it should only be the matter of writing a new function for +widget->style->klass->draw_hline + +I did a quick experiment with that and there were no problems with those +attributes. +I guess reality will prove me to be wrong though... ;-) + +// Jörgen Viksell +_____________________________________________________________________________________ +Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com + + + +RE: [Dillo-dev]Re: + +From: Eric GAUDET - 2000-11-28 02:22 + +-- En reponse de "[Dillo-dev]Re:" de Sebastian Geerken, le 27-Nov-2000 : +> Jorge Arellano Cid writes: +> > Hrulers +> > +> > I considered patches from Allan, Eric and some progress by +> > Sebastian. +> > +> > Hrulers will have to be reimplemented for the new Dw, and as +> > both patches implemented a resize mechanism that's not the one +> > that current-Dw uses, and because both showed several problems +> > (incompletness or fails) I'd prefer to wait for the new Dw and +> > try to construct the hruler based upon the good ideas that both +> > patches showed. +> +> Both patches will be obsolete, this is already working (very +> different) in the new Dw with embedded GtkHSeparator's (but for +> support of all attributes of

there is still the need for a new +> DwHRuler). +> +> Sebastian + +GtkHSeparator doesn't seem to have all the features needed for painting +a HR tag with attributes : no line thickness (-> no SIZE attribute), +only 3d-rendering (-> no NOSHADE attribute). +Will it be a problem ? + +----------------------------------- +Eric GAUDET +Le 28-Nov-2000 a 11:17:54 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Re: + +From: Eric GAUDET - 2000-11-28 01:58 + +-- En reponse de "[Dillo-dev]Re:" de Jorge Arellano Cid, le 27-Nov-2000 +: +> Pagemarks: This must be moved to the rightmost-button menu and +> set insensitive when there're no headings in the page. +> + +I'll do it soon. + +----------------------------------- +Eric GAUDET +Le 28-Nov-2000 a 10:58:23 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Re: + +From: Sebastian Geerken - 2000-11-27 23:34 + +Jorge Arellano Cid writes: +> Hrulers +> +> I considered patches from Allan, Eric and some progress by +> Sebastian. +> +> Hrulers will have to be reimplemented for the new Dw, and as +> both patches implemented a resize mechanism that's not the one +> that current-Dw uses, and because both showed several problems +> (incompletness or fails) I'd prefer to wait for the new Dw and +> try to construct the hruler based upon the good ideas that both +> patches showed. + +Both patches will be obsolete, this is already working (very +different) in the new Dw with embedded GtkHSeparator's (but for +support of all attributes of
there is still the need for a new +DwHRuler). + +Sebastian + + + +Re: [Dillo-dev]Misc. + +From: Livio Baldini Soares - 2000-11-27 18:33 + +Livio Baldini Soares writes: + + + +> I put in a patch for this, it's bug number is 100. I put in that I +> was going to work on it.... but I guess I did something wrong and only +> my name appeared, is it possible for me to change the `Being worked:` +> field? If not, Jorge could you change it to livio@li..., I +> think it's much more informative than just `Livio`. + +Nevermind, just changed it to show my e-mail, sorry about that... + +bye yall, + +-- +Livio + + + +Re: [Dillo-dev]Misc. + +From: Livio Baldini Soares - 2000-11-27 18:17 + +Jorge Arellano Cid writes: +> +> Hi there! +> + +Hi Jorge, + +I liked the new version (0.3.0) a lot. Nice work. By the way, +if by any chance I get the chance to patch anything, then I should +probably patch against CVS, right? Another thing, do you (or anybody +else) have anything against sending patches to the list, so everyone +can "pitch" in, and publically(?) discuss them. If not do you want me +to CC: them to you, Jorge? + +> - There's a small bug within a_Url_squeeze. When there're too +> much "/.." sequences in the URL, it removes the server! + + + +> +> Patches for these BUGs, and their bug-track-entries, would be +> appreciated. +> + +I put in a patch for this, it's bug number is 100. I put in that I +was going to work on it.... but I guess I did something wrong and only +my name appeared, is it possible for me to change the `Being worked:` +field? If not, Jorge could you change it to livio@li..., I +think it's much more informative than just `Livio`. + +best regards to all, + +-- +Livio + + + +[Dillo-dev]Re: + +From: Jorge Arellano Cid - 2000-11-27 16:25 + +Hi! + + +The code with the Findtext and Pagemarks is in the CVS. The +server reported no problems when uplading, so I hope its working +(there were several BUG reports at sourceforge for this; Ah, and +sourceforge's download counters had gone carzy too!!! Dillo shows +a negative download rate the day with the highest peak of page +visits!!! :-) + +Back to Findtext: this implementation is a basic one, there's +still work to do. Most notably stripping of '\n\r\t' and spaces +when adding to the Text buffer, feedback messages and finally a +port to the new Dw when it's ready. + +Pagemarks: This must be moved to the rightmost-button menu and +set insensitive when there're no headings in the page. + +----- +Dillo in a 64bit machine: + +> Actually it does work on 64-bit systems. I currently run it on an Alpha +> It isn't my main browser (yet), but it is slowly getting there. FYI I +> also maintain the Debian dillo package. + +I'm very happy to know it works!!! (my efforts haven't been +wasted!). + +In regard to the slow progress, I agree with you, and its +mostly due to an effort to clean and implement design solutions +in the code that serve as framework for future enhancement: +networking has been rewritten, Dw is getting a new design and +plugins are being developed to simplify several tasks. If we +succeed with them, I hope we can see faster improvement in the +future. bear with us and let's get there! + +> A friend of mine as access to several sparc stations (both 32 and 64 +> bits, under linux and solaris 8). I asked him to test Dillo. + +Thanks. +Actually dillo works perfectly on a Sparc 32, but the Sparc 64 +and Solaris architectures haven't been tested. I'll be expecting +that info. + +--- +Hrulers + +I considered patches from Allan, Eric and some progress by +Sebastian. + +Hrulers will have to be reimplemented for the new Dw, and as +both patches implemented a resize mechanism that's not the one +that current-Dw uses, and because both showed several problems +(incompletness or fails) I'd prefer to wait for the new Dw and +try to construct the hruler based upon the good ideas that both +patches showed. + +slangley: +I saw your entry (BUG#62) and I'd prefer you to work it with +the new Dw (just not to waste your efforts). + +--- + +>> - There a small bug within a_Url_squeeze. When there're too +>> much "/.." sequences in the URL, it removes the server! +> +> How-to reproduce it ... ? + +Try something like: + +http://some.site.org/../main.html or +http://some.site.org/../main.html + +they should resolve to http://some.site.org/main.html + +--- + +> I'm having the hardest time making bug-track-entries : 99% of the time +> I'm getting : +> +> Internal Server Error ... + +I just made an entry from other network, for Find Text (BUG#99). +If someone else has problems please tell me. + + + + +Jorge.- + + + +RE: [Dillo-dev]Misc. + +From: Eric GAUDET - 2000-11-27 14:44 + +-- En reponse de "[Dillo-dev]Misc." de Jorge Arellano Cid, le +25-Nov-2000 : +> Patches for these BUGs, and their bug-track-entries, would be +> appreciated. +> + +I'm having the hardest time making bug-track-entries : 99% of the time +I'm getting : +<< +Internal Server Error + +The server encountered an internal error or misconfiguration and was +unable to complete your request. + +Please contact the server administrator, root@localhost and inform +them of the time the error occurred, and anything you +might have done that may have caused the error. + +More information about this error may be available in the server error +log. + +Apache/1.3.12 Server at huallepen.inf.utfsm.cl Port 80 +>> + +BTW: if comment and howto-reproduce lines are limited to 256 chars, it +would be easier for everbody to ask for : +ROWS=4 COLS=64 +instead of the stupid : +ROWS=5 COLS=80 +('see what I mean ? ;-) + +... And since I'm talking about the bug-track engine, it would be nice +to have a "Wish insertion page" : all unimplemented features are not +"bugs", and I'm not sure I want to see "I'd like to have SSL", "I'd +like a single download window" pollute the bug list. +I don't want them forgotten when we'll be looking for new features +implementation and long term projects. +(would a poll be hard to implement, for most-wanted features ?) + +----------------------------------- +Eric GAUDET +Le 27-Nov-2000 a 23:18:12 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Misc. + +From: Eric GAUDET - 2000-11-27 01:36 + +-- En reponse de "[Dillo-dev]Misc." de Jorge Arellano Cid, le +25-Nov-2000 : +> - A "Copy link location" item (to allow pasting) + +I'm going to try that, but I can't promise anything. + +> - There's a small bug within a_Url_squeeze. When there're too +> much "/.." sequences in the URL, it removes the server! + +How-to reproduce it ... ? + +----------------------------------- +Eric GAUDET +Le 27-Nov-2000 a 10:35:44 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Misc. + +From: Ron Farrer - 2000-11-26 16:30 + +Attachments: Message as HTML + +Eric GAUDET (egaudet@in...) wrote: + +> If you know some C, would you mind investigating and trying to fix +> alpha-specific bug#89 and 90 ? (since you're the only alpha-guy around +> ;-) + +Is there a way of contacting whoever submitted bug#89? I am unable to +get dillo to segfault on lwn.net. Also, bug#90 is using a non-free +compiler.. I can't help with that. + +Ron +--=20 +Email: , +Home: +Alpha Linux Powered: + + + +Re: [Dillo-dev]Misc. + +From: Eric GAUDET - 2000-11-26 12:30 + +-- En reponse de "Re: [Dillo-dev]Misc." de Ron Farrer, le 26-Nov-2000 : +> Actually it does work on 64-bit systems. I currently run it on an +> Alpha +> It isn't my main browser (yet), but it is slowly getting there. FYI I +> also maintain the Debian dillo package. +> + +If you know some C, would you mind investigating and trying to fix +alpha-specific bug#89 and 90 ? (since you're the only alpha-guy around +;-) + +----------------------------------- +Eric GAUDET +Le 26-Nov-2000 a 21:27:05 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev][ANN]Preferences plugin ! + +From: Eric GAUDET - 2000-11-26 12:24 + +Hi, +I just published my Preferences Dillo-plugin at my now usual address +(http://www.rti-zone.org/dillo/) +Fully working : it writes dillorc ! (provided your dillo's patched for +"dpi" ;-) +With a screenshot ! + +----------------------------------- +Eric GAUDET +Le 26-Nov-2000 a 21:19:18 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Misc. + +From: Ron Farrer - 2000-11-26 05:24 + +Attachments: Message as HTML + +Eric GAUDET (egaudet@in...) wrote: + +> -- En reponse de "[Dillo-dev]Misc." de Jorge Arellano Cid, le +> 25-Nov-2000 : +> > - Make Dillo work in a 64bit machine! (I worked on this a lot, +> > but I no longer have access to the machine I was using). +> >=20 +>=20 +> A friend of mine as access to several sparc stations (both 32 and 64 +> bits, under linux and solaris 8). I asked him to test Dillo. + +Actually it does work on 64-bit systems. I currently run it on an Alpha +It isn't my main browser (yet), but it is slowly getting there. FYI I=20 +also maintain the Debian dillo package.=20 + +Ron +--=20 +Email: , +Home: +Debian on Alpha: + + + +[Dillo-dev]Tiny bug in FORM checkboxes + +From: Eric GAUDET - 2000-11-26 03:04 + +Hi, +There's a tiny bug in the CHECKBOX handling : if no VALUE attribute is +specified, the checked-box value is an empty string ; the default value +should be "on" so one can differentiate a checked box with an empty +TEXT input. +If it's not a bug, it's definitely annoying for POST parsing. + +Here's how to fix it : (dillo v0.3.0) +in html.c : line 1645 +- init_str = ""; ++ init_str = "on"; + +----------------------------------- +Eric GAUDET +Le 26-Nov-2000 a 11:57:59 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Misc. + +From: Eric GAUDET - 2000-11-26 01:29 + +-- En reponse de "[Dillo-dev]Misc." de Jorge Arellano Cid, le +25-Nov-2000 : +> - Make Dillo work in a 64bit machine! (I worked on this a lot, +> but I no longer have access to the machine I was using). +> + +A friend of mine as access to several sparc stations (both 32 and 64 +bits, under linux and solaris 8). I asked him to test Dillo. + +----------------------------------- +Eric GAUDET +Le 26-Nov-2000 a 10:28:01 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Misc. + +From: Will Newton - 2000-11-25 14:57 + +On Sat, 25 Nov 2000, Jorge Arellano Cid wrote: + +> Although a bit outdated, there's a "project notes" link that +> has some hints on this subject. If you want to work on it, let me +> know, cause I'll have to tune the networking part in order to +> make it functional. + +Have you considered using w3c libwww for networking? It's part of GNOME +now and is available for most ditros. +(It does HTTP/1.1, SSL and lots of other nice things) + + + +[Dillo-dev]Misc. + +From: Jorge Arellano Cid - 2000-11-25 14:18 + +Hi there! + +When reading the mailing-list, there were several topics so, +here go my comments and answers: + +> If I hit a slow site, I get no visual clue that dillo is doing +> anything. To see this first hand, go to bugs.debian.org, and look +> up the package lintian. dillo seems to hang, then magically load +> the page. + +The Stop button may suggest some activity, but that's certainly +not enough... +I thought that a small panel to the left of the progress bars +can be a good solution. I mean a table like this: + +,--------------. +| Dns | Send | [Image progress bar] +| Retr | Close | [Text progress bar ] +`--------------' + +Those words in the panel can be highlighted when the +correspondent activities are taking place. + + +> Robert investigated the problem (bug#97) a little more. It appears to +> be a gcc 2.95.2 bug for K6 with -O2 option. I heard about that for +> non-i386 cpu (SH4, ARM). It seems -O2 is not reliable for now, except +> for intel processors. +> +> We should put a warning in the README about this. + +OK, that'll be in the README file of our next release. + + +> * Downloads +> Rather than having loads of dialogs like in Netscape, a single +> window with a list of downloads and status would be cool (imagine +> a more simple GetRight style window). + +Although a bit outdated, there's a "project notes" link that +has some hints on this subject. If you want to work on it, let me +know, cause I'll have to tune the networking part in order to +make it functional. + +--- + +Some patching suggestions: + +- A "Copy link location" item (to allow pasting) +- There's a small bug within a_Url_squeeze. When there're too +much "/.." sequences in the URL, it removes the server! +- Make Dillo work in a 64bit machine! (I worked on this a lot, +but I no longer have access to the machine I was using). + +Patches for these BUGs, and their bug-track-entries, would be +appreciated. + + +--- + +Finally, when integrating the Find-text patch, I noticed that +it only works for the first match, so I got into it and now I +have a Find-text that does it. I'll send a note to the list when +I upload the code to the CVS. + + +Jorge.- + + + +RE: [Dillo-dev]Suggestions + +From: Will Newton - 2000-11-24 15:50 + +On Thu, 23 Nov 2000, Sean 'Shaleh' Perry wrote: + +> I have suggested this. Jorge is not 100% convinced. Plus dillo needs some +> rework to handle css. html items have no storage of names. So you can't do +>
. + +I'll write a CSS parser if you want (a quick search on google says the +only C CSS parser is in Amaya... I advise any children watching to avert +their eyes from that code...). + + + +RE: [Dillo-dev]Suggestions + +From: Eric GAUDET - 2000-11-24 13:26 + +-- En reponse de "[Dillo-dev]Suggestions" de Will Newton, le +24-Nov-2000 : +> +> Here are a few ideas/suggestions I have: +> +> * Errors +... +> Also, an error log window would be cool (it could be global so all +> browser windows could output to it). Then I can see why the image +> didn't load or get more verbose error messages. You could use +> simple printfs to the console for this, but I think this way is +> better. +> + +Warnings an errors are reported to stderr, so you can read them on +there term where you launched dillo. +However, that's true dillo's status indications needs some work. + +> * Images +> Is alpha handled properly on images? I have seen some black borders +> round icons. +> + +See bug-track engine : transparency is supported for GIF images, but +not for PNG. + +> * Downloads +> Rather than having loads of dialogs like in Netscape, a single window +> with a list of downloads and status would be cool (imagine a more +> simple GetRight style window). +> + +There's no download at all for now : where're all thinking about it, +but the feature and the actual implementation have yet to but discussed. +Your suggestion seem to be what most people want, though. Netscape +for macintosh does this. + +> * CSS +> CSS can be used well like in Mozilla for preferences e.g. you store +> default font/colors in a user.css file and these settings "cascade" +> down. +> + +This have been discussed before, and rejected for now for two reasons : +- CSS support seems very far to be implemented ; +- CSS can't handle every option we want (page-rendering only). + +> There's also no "About" dialog. :) +> + +Right ! Why don't you make one, just to train your skills on Dillo ? :-) + +> Anyway, these are just a few ideas I have, although some of them +> would obviously be in the future. I'm going to look at adding CSS +> support as soon as I untangle the source code a little. :) +> + +You're welcome. Don't hesitate to ask any (stupid or not ;-) question +to the list, but make sure you've read everything on dillo's homepage, +documentation and mail list archive. + +----------------------------------- +Eric GAUDET +Le 24-Nov-2000 a 22:13:29 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev][patch] Dillo-plugins final + +From: Eric GAUDET - 2000-11-24 12:12 + +Hi all, +I just released the final version of my patch for Dillo-plugins for you +"I-want-the-last-patch" freaks, and also for those who want to give it +a try and send me some comments or bug repports. + +Visit my dedicated web page, now permanent at : +http://www.rti-zone.org/dillo/ + +----------------------------------- +Eric GAUDET +Le 24-Nov-2000 a 21:09:42 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Suggestions + +From: Sean 'Shaleh' Perry - 2000-11-24 06:28 + +> +> * CSS +> CSS can be used well like in Mozilla for preferences e.g. you store +> default font/colors in a user.css file and these settings "cascade" down. +> + +I have suggested this. Jorge is not 100% convinced. Plus dillo needs some +rework to handle css. html items have no storage of names. So you can't do +
. + + + +[Dillo-dev]Suggestions + +From: Will Newton - 2000-11-24 03:31 + +Here are a few ideas/suggestions I have: + +* Errors +Errors IMO should appear in the main window and not in any dialogs like in +Nestcape. Dillo does this, I know, but I wanted to make sure it stays like +that. :) +Also, an error log window would be cool (it could be global so all browser +windows could output to it). Then I can see why the image didn't load or +get more verbose error messages. You could use simple printfs to the +console for this, but I think this way is better. + +* Images +Is alpha handled properly on images? I have seen some black borders round +icons. + +* Downloads +Rather than having loads of dialogs like in Netscape, a single window with +a list of downloads and status would be cool (imagine a more simple +GetRight style window). + +* CSS +CSS can be used well like in Mozilla for preferences e.g. you store +default font/colors in a user.css file and these settings "cascade" down. + +There's also no "About" dialog. :) + +Anyway, these are just a few ideas I have, although some of them would +obviously be in the future. I'm going to look at adding CSS support as +soon as I untangle the source code a little. :) + + + +RE: [Dillo-dev]Status + +From: Sean 'Shaleh' Perry - 2000-11-24 03:17 + +On 24-Nov-2000 Will Newton wrote: +> +> I got the latest beta of Dillo (0.3.0) and it seems pretty fast, but no +> tables means it can't render much. Is tables the next feature to be added? +> CSS support would also be cool. I'm currently looking through the source +> to see where I can help out. +> + +Once the new Dw widget appers, I will begin integrating my work on html.c. I +have nearly all font affecting tags working. All that is left is tables and +frames, and tags that do not directly affect rendering like abbr. If I recall, +someone else is working on div. + +If you would like to make a css parser, that would be handy. CSS support will +be a while, there are more pressing issues. + + + +FW: RE: [Dillo-dev]dillo 0.3.0 crashes at startup + +From: Eric GAUDET - 2000-11-24 01:26 + +Robert investigated the problem (bug#97) a little more. It appears to +be a gcc 2.95.2 bug for K6 with -O2 option. I heard about that for +non-i386 cpu (SH4, ARM). It seems -O2 is not reliable for now, except +for intel processors. + +We should put a warning in the README about this. + +-------------------------- FW -------------------------------- +Program received signal SIGSEGV, Segmentation fault. +Dw_border_size_nego_y (dw=0x8054290, allocation=0x80b0a18) at +dw_border.c:64 +64 dw->allocation = *allocation; + + +locals: +dw = (Dw *) 0x8054290 +allocation = (DwRect *) 0x80b0a18 + +> -O2 seems to pose problems in 2.95.2. Can you try -O or -O0 (O-zero) +> with k6 ? + +"-O2 -mcpu=pentium" works fine. +"-O0 -mcpu=k6 -march=pentium -g3" works fine also. +"-O -mcpu=k6 -march=pentium -g3" works fine as well, but +"-O2 -mcpu=k6 -march=pentium -g3" doesn't work. Then again +"-O6 -mcpu=pentium -march=pentium -g3" DOES work. + +I think setting -cpu=k6, or ever worse, -march=k6 (had problems with +this one before..) causes some type of code to be miscompiled in some +cases when you use -O2. If -O2 fails at compile-time (for me) it starts +to loop infinitly. In these cases only -O0 works, so 2.95.x is kinda +buggy. I hope the 3.0 series will be better. + +> -g is always a good idea for debugging ;-) + +Yes, and you can always strip the binary when your'e done. +By the way, "-W -Wall" is a LOT better at catching dirty code than just +-Wall. Try it and see for yourself :). + +Put a note of this in some FAQ somewhere so that you can tell the next +victim of this gcc bug to "read the friendly manual" :). + +Thanks, Robert. + +--------------End of forwarded message------------------------- + +----------------------------------- +Eric GAUDET +Le 24-Nov-2000 a 10:17:57 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Status + +From: Will Newton - 2000-11-24 00:52 + +I got the latest beta of Dillo (0.3.0) and it seems pretty fast, but no +tables means it can't render much. Is tables the next feature to be added? +CSS support would also be cool. I'm currently looking through the source +to see where I can help out. + + + +RE: [Dillo-dev]dillo 0.3.0 crashes at startup + +From: Eric GAUDET - 2000-11-23 01:21 + +What version of dillo ? +Can you send a stack dump after the crash ? +Are you on a i386 arch ? if so, can you send me your dillo binary ? + +PS: the list is very low traffic, if you register you won't be annoyed +by more than 3 or 4 messages a week. + +-- En reponse de "[Dillo-dev]dillo 0.3.0 crashes at startup" de Robert +Holmberg, le 22-Nov-2000 : +> Ahh..CRAP! Just submitted bug #97 with too many characters and only +> half the bug description was submitted.. here we go: +> +> Dillo crashes on startup (gcc 2.95.2, glibc 2.1.2) after showing an +> empty +> window. It does show contents (menu, toolbar..) in the window if run +> through gdb: +> +> (gdb) run +> Starting program: /usr/local/bin/dillo +> dillo_dns_init: Here we go! +> Loading bookmarks... +> [New Thread 3591 (manager thread)] +> [New Thread 3590 (initial thread)] +> [New Thread 3592] +> +> Program received signal SIGSEGV, Segmentation fault. +> 0x8061c00 in Dw_border_size_nego_y () +> +> Please CC questions to me, I'm not on the list. +> +> Robert. +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +----------------------------------- +Eric GAUDET +Le 23-Nov-2000 a 10:17:40 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Dillo 0.3.0 crash on starup. + +From: Robert Holmberg - 2000-11-22 21:22 + +Hust submitted bug #97 w. more than 256 characters in description in the +bugtarcker. Here's the whole deal: + +Dillo 0.3.0, gcc 2.95.2, glibc 2.1.2, linux 2.4-test11: + +(gdb) run +Starting program: /usr/local/bin/dillo +dillo_dns_init: Here we go! +Loading bookmarks... +[New Thread 3621 (manager thread)] +[New Thread 3620 (initial thread)] +[New Thread 3622] + +Program received signal SIGSEGV, Segmentation fault. +0x8061c00 in Dw_border_size_nego_y () + +Dillo does draw it's window first. + +I'm NOT suscribed to the list. + +Robert. + + + +[Dillo-dev]dillo 0.3.0 crashes at startup + +From: Robert Holmberg - 2000-11-22 21:17 + +Ahh..CRAP! Just submitted bug #97 with too many characters and only half +the bug description was submitted.. here we go: + +Dillo crashes on startup (gcc 2.95.2, glibc 2.1.2) after showing an empty +window. It does show contents (menu, toolbar..) in the window if run +through gdb: + +(gdb) run +Starting program: /usr/local/bin/dillo +dillo_dns_init: Here we go! +Loading bookmarks... +[New Thread 3591 (manager thread)] +[New Thread 3590 (initial thread)] +[New Thread 3592] + +Program received signal SIGSEGV, Segmentation fault. +0x8061c00 in Dw_border_size_nego_y () + +Please CC questions to me, I'm not on the list. + +Robert. + + + +[Dillo-dev]BUG#95 + +From: Jorge Arellano Cid - 2000-11-22 01:27 + +Hi! + + +I hope you're enjoying the 0.3.0 release! +(I haven't received complaints) + +There're still several things to do, and I'll try them one by +one... + +I'm still concerned with BUG#95, and followed an interesting +thread at http://www.flora.org/lynx-dev/lynx-dev/9608/0278.html + +Even more, further research showed me that this issue is far +from being easy to solve, but the "trend" seems to use what Fote +suggested in the previous thread (0283.html). + +The page suggested in the bugtrack engine has changed to this +standard, so now its browsable with dillo without any change! And +I also remember that some time ago, sourceforge included +directions for displaying their logo with an image URL that +included a & sequence, but not anymore! + +So it seems that things are getting straight in an attempt to +keep CGI functionality working ('&' in that context is a reserved +character to separate name=value pairs, and any use of it for +other purpose should be hex escaped). + + +Please send me any comments, specially if you can prove it +MUST be handled in another way, otherwise I'll delete the entry +within a few days. + + +Jorge.- + + + +Re: [Dillo-dev]Font issues + +From: Sebastian Geerken - 2000-11-16 01:59 + +Eric GAUDET wrote: +> +> I've just upgraded Netscape to 4.75 (mandrake RPM) which _needs_ the +> package mozilla-fonts. These fonts seem to be buggy : the +> -helvetica-medium-italic- is a bitmap 18pts font looking bold, and it's +> ugly when resized in 12 by Dillo for regular italic. +> One way around is to change Dillo to use "oblique" instead of "italic": +> +> in dw_page.c (v0.3.0) +> in static GdkFont *Dw_page_realize_font(DwPageFont *font) +> line 1115: +> - font->italic ? "i" : "r", +> + font->italic ? "o" : "r", + +And a few lines below: +if (font->font == NULL && font->italic) { +- /* Some italic fonts (e.g. Courier) use "o" instead of "i". */ +- sprintf(fontname, "-*-%s-%s-o-*-*-%d-*-75-75-*-*-*-*", ++ /* Some italic fonts (e.g. Courier) use "i" instead of "o". */ ++ sprintf(fontname, "-*-%s-%s-i-*-*-%d-*-75-75-*-*-*-*", +font->name, +font->bold ? "bold" : "medium", +font->size); +font->font = gdk_font_load(fontname); +} + +> That looks like an extreme solution to change Dillo when a font is +> buggy, but it works. (BTW, my adode and urw helvetica don't have italic +> face, only oblique : X must be switching to oblique when italic's not +> found ; does any distri have helvetica-oblique ?) + +It's dillo, which switches to oblique. + +> A better way would be to make that an option in dillorc. +> Perhaps Sean has something better with his fonts handling (or a better +> ideas) ? + +Oblique and italics are two different variants, actually you get an +oblique variant by shearing a font, but an italic variant is a totally +new font. Helvetica Italics is quite unusual, as well as e.g. Times +Oblique. On my system, only Adobe Courier provides both variants. + +However, HTML does not distinguish between these variants, but CSS +does. Personally I prefer oblique variants, since they are more +readable at low resolutions. A option letting the user decide which +variant dillo should prefer, when both are available, would imho be a +good possibility. + +Sebastian + + + +Re: [Dillo-dev]where did view source go? + +From: Eric GAUDET - 2000-11-15 09:20 + +-- En reponse de "Re: [Dillo-dev]where did view source go?" de +Sebastian Geerken, le 14-Nov-2000 : +>> aaarrggghhh, where did view source go? how can I tell why dillo +>> chose to +>> render a web page like it did if I can not see the html? +> +> Yes, somehow a complete menu got lost ... commented in +> a_Menu_mainbar_new. + +It's in the popup menu now. + +----------------------------------- +Eric GAUDET +Le 15-Nov-2000 a 18:19:45 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]where did view source go? + +From: Sean 'Shaleh' Perry - 2000-11-15 07:13 + +> +> BTW, never wondered about the term "View Source"? Actually, there +> *aren't* sources for html documents (except pl, php, asp ...), the +> menu entry should be named "View As Plain Text". +> + +"source" as an abstraction. It may be cgi generated, static, etc. Perhaps +"View Markup"? + + + +Re: [Dillo-dev]where did view source go? + +From: Sebastian Geerken - 2000-11-14 20:49 + +Sean 'Shaleh' Perry wrote: +> +> aaarrggghhh, where did view source go? how can I tell why dillo chose to +> render a web page like it did if I can not see the html? + +Yes, somehow a complete menu got lost ... commented in +a_Menu_mainbar_new. + +BTW, never wondered about the term "View Source"? Actually, there +*aren't* sources for html documents (except pl, php, asp ...), the +menu entry should be named "View As Plain Text". + +Sebastian + + + +[Dillo-dev]Bug#95 : not a bug ! + +From: Eric GAUDET - 2000-11-14 13:07 + +I just parsed the bugtrack engine, and bug#95 puzzled me : I never +heard of entities in URLs before, even in the RFC. The only official +escape mecanism for URLs is %XX where X is hexadecimal ; +non escaped characters are UTF-8 (which is very close to ISO8859-1 ?). +HTML4 specs has a note about that : some old browsers accept this +undocumented URL parsing, and some bad pages rely on that. + +----------------------------------- +Eric GAUDET +Le 14-Nov-2000 a 21:55:49 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]where did view source go? + +From: Eric GAUDET - 2000-11-14 12:15 + +-- En reponse de "[Dillo-dev]where did view source go?" de Sean +'Shaleh' Perry, le 14-Nov-2000 : +> aaarrggghhh, where did view source go? how can I tell why dillo +> chose to render a web page like it did if I can not see the html? + +Would somebody be see a problem make view source a Dillo-plugin ? + +----------------------------------- +Eric GAUDET +Le 14-Nov-2000 a 20:21:20 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]where did view source go? + +From: Sean 'Shaleh' Perry - 2000-11-14 08:13 + +aaarrggghhh, where did view source go? how can I tell why dillo chose to +render a web page like it did if I can not see the html? + + + +[Dillo-dev]dillo does not give enough user feedback + +From: Sean 'Shaleh' Perry - 2000-11-14 08:07 + +If I hit a slow site, I get no visual clue that dillo is doing anything. To +see this first hand, go to bugs.debian.org, and look up the package lintian. +dillo seems to hang, then magically load the page. + + + +Re: [Dillo-dev]New 0.3.0 release + +From: Sean 'Shaleh' Perry - 2000-11-14 07:42 + +> I downloaded it a few hours ago, and patched the changes into my +> version (a bit "handwork" was necessary). I already tested +> third-button-menus and some new tags implemented by Jörgen (, +> and ), and that seems to work. +> + +awesome, those were the last three tags. I thing once my changes are merged +into dillo the only tags not supported are the non display tags (like abbr or +address) and sub and sup. + + + +RE: [Dillo-dev]Font issues + +From: Sean 'Shaleh' Perry - 2000-11-14 07:41 + +> A better way would be to make that an option in dillorc. +> Perhaps Sean has something better with his fonts handling (or a better +> ideas) ? +> + +font handling is actually the next thing on my list. Hmm, I have Xfree 4.0.1 +and all still seems well. + + + +[Dillo-dev]Font issues + +From: Eric GAUDET - 2000-11-14 02:01 + +I've just upgraded Netscape to 4.75 (mandrake RPM) which _needs_ the +package mozilla-fonts. These fonts seem to be buggy : the +-helvetica-medium-italic- is a bitmap 18pts font looking bold, and it's +ugly when resized in 12 by Dillo for regular italic. +One way around is to change Dillo to use "oblique" instead of "italic": + +in dw_page.c (v0.3.0) +in static GdkFont *Dw_page_realize_font(DwPageFont *font) +line 1115: +- font->italic ? "i" : "r", ++ font->italic ? "o" : "r", + +That looks like an extreme solution to change Dillo when a font is +buggy, but it works. (BTW, my adode and urw helvetica don't have italic +face, only oblique : X must be switching to oblique when italic's not +found ; does any distri have helvetica-oblique ?) +A better way would be to make that an option in dillorc. +Perhaps Sean has something better with his fonts handling (or a better +ideas) ? + +----------------------------------- +Eric GAUDET +Le 14-Nov-2000 a 10:47:37 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]New 0.3.0 release + +From: Sebastian Geerken - 2000-11-13 14:38 + +Jorge Arellano Cid wrote: +> +> Hi! +> +> The sourceforge shell acccount server is back and dillo-0.3.0 +> is there, ready for download. +> +> Note that there're still some patches in my queue and they'll +> have to wait until 0.3.1 (This release is a long delayed one and +> I didn't wanted to procrastinate it even more). +> +> I hope you enjoy this release, but bear in mind that 0.3.0 +> is an intermediate release before 0.3.1. +> +> Jorge.- +> +> Ps: I'll be expecting some feedback! + +I downloaded it a few hours ago, and patched the changes into my +version (a bit "handwork" was necessary). I already tested +third-button-menus and some new tags implemented by Jörgen (, + and ), and that seems to work. + +I hope I'll be able to "release" a slow, buggy, but basicly working +Dw, integrated in dillo 0.3.0, within the next few days. + +Sebastian + + + +[Dillo-dev]New 0.3.0 release + +From: Jorge Arellano Cid - 2000-11-13 13:01 + +Hi! + +The sourceforge shell acccount server is back and dillo-0.3.0 +is there, ready for download. + +Note that there're still some patches in my queue and they'll +have to wait until 0.3.1 (This release is a long delayed one and +I didn't wanted to procrastinate it even more). + +I hope you enjoy this release, but bear in mind that 0.3.0 +is an intermediate release before 0.3.1. + + +Jorge.- + +Ps: I'll be expecting some feedback! + + + +[Dillo-dev]dillo-0.3.0 + +From: Jorge Arellano Cid - 2000-11-12 18:07 + +Hi! + + +The dillo-0.3.0 version is ready and waiting for release. The +funny thing is that the sourceforge server (shell accounts) +refuses foreign connections! I've been trying for a couple of +days and also wrote the support staff there asking for some news. +When the server comes up, 0.3.0 will be there. + + +Jorge.- + + + +RE: [Dillo-dev]CVS update + +From: Eric GAUDET - 2000-11-10 02:51 + +-- En reponse de "[Dillo-dev]CVS update" de Jorge Arellano Cid, le +09-Nov-2000 : +> +> Hi! +> +> We're getting closer to 0.3.0 release. I just updated the CVS +> server (and bug-track engine) with the newest version. +> + +I'll post the complete/clean Dillo-plugins patch against v0.3.0 then +(this should make it easier for you) + +> - The horizontal rulers patch (worked by Eric and Allan). Which +> one is the latest patch? Allan says its patch takes into +> account feedback from Jörgen and Eric. And I also have a +> patch from Eric :-) +> Please tell me which one to apply or send me a new one +> against the CVS code. +> + +I know nothing about Allan's patch. Mine is dated Aug 26 and I haven't +touched it since. Mine is complete though : all attributes are +recognized and redendered,
before and after the
(see more +details on my page). + +> - Bug#80 worked by Eric. The Web site doesn't contain a valid +> diff file for it (please send me that patch Eric). +> + +Oops, sorry. Site updated. As it's a tiny patch, it's also in this mail. + +> - For BUG#27. Which test pages did you use Eric? Please send me +> some URLs. +> + +It's in the Html.testsuite. (There was no link from the index to the +page, but the page was here along with the images, sorry : updated on +my page). Link : Image Maps + +PS: patch for bug #80: (my mailer is puting some \n in the way, +prefer my page's version :-/) + +diff -pur dillo-0.2.4/src/dw_page.c dillo-0.2.4.bug80/src/dw_page.c +--- dillo-0.2.4/src/dw_page.c Tue Aug 22 00:54:09 2000 ++++ dillo-0.2.4.bug80/src/dw_page.c Sun Aug 27 22:15:18 2000 +@@ -34,7 +34,7 @@ +#include "prefs.h" +#include "commands.h" + +-#define DW_GET_BW(page) (BrowserWindow *)((page)->status_data) ++#define DW_GET_BW(page) (page->status?(BrowserWindow +*)((page)->status_data):NULL) + +/* +* Set GtkDwScroller::anchor_pos value. +@@ -670,9 +670,9 @@ static void Dw_page_handle_event(Dw *dw, +menu_popup.info.url = page->links[link_pressed].url; +gtk_menu_popup(GTK_MENU(menu_popup.menu_over_link), NULL, +NULL, +NULL, NULL, button->button, button->time); +- } else { +- if (bw->nav_stack_size == 0) +- return; ++ } else if (bw) { ++ if (bw->nav_stack_size == 0) ++ return; + +menu_popup.info.title = +bw->nav_stack[bw->nav_stack_ptr].title; +menu_popup.info.url = bw->nav_stack[bw->nav_stack_ptr].url; + + + +----------------------------------- +Eric GAUDET +Le 10-Nov-2000 a 11:34:29 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]CVS update + +From: Jorge Arellano Cid - 2000-11-09 16:45 + +Hi! + +We're getting closer to 0.3.0 release. I just updated the CVS +server (and bug-track engine) with the newest version. + +Please note how important is to use the bug-track engine and +not to do silent patching. The new Changelog (in CVS) shows a lot +of small patches some of whom were not recorded in the bug-track. +Please avoid this kind of situation. + +On the progress side, the new code hasn't solved all the +problems related with link-following before the page arrives, but +certainly will not crash if you follow a different link while +still downloading the referer page! (I hope to finish that in +0.3.1 release). + +I also started moving the patch queue, and I have a few doubts: + +- The horizontal rulers patch (worked by Eric and Allan). Which +one is the latest patch? Allan says its patch takes into +account feedback from Jörgen and Eric. And I also have a +patch from Eric :-) +Please tell me which one to apply or send me a new one +against the CVS code. + +- Bug#80 worked by Eric. The Web site doesn't contain a valid +diff file for it (please send me that patch Eric). + +- The Find text patch (originally from Sam, patched by +Sebastian and repatched by Allan). Allan, is your final +version a stable feature. I ask because Sam warned us of some +bugs in the patch. I guess they were worked out by following +patches, and you being the last one to work out the code, and +most probably the one who has tested it more extensively, +may have the best informed answer. + +- For BUG#27. Which test pages did you use Eric? Please send me +some URLs. + + +Jorge.- + + +PS1: Having a user manual (an HTML page) has started to be +necessary. A very concise guide. Volunteers? + +PS2: There's a small bug within a_Url_squeeze. When there're +too much "/.." sequences in the URL, it removes the server! +(a patch for this BUG, and its bug-track-entry would, be highly +appreciated too). + +PS3: If someone takes the time to update the bug-track with the +missing entries (found in the CVS-Changelog) that'd be very +helpful too. + + + +[Dillo-dev]Dillo Weekly News + +From: Allan Clark - 2000-11-05 15:45 + +Just posted you can view it here +http://www.shark.pwp.blueyonder.co.uk/news/news051100.html + + +Allan Clark +allan@al... +shark@bl... + + + +[Dillo-dev]Internal release + +From: Jorge Arellano Cid - 2000-11-03 22:49 + +Hi! + +The internal release has a new code layer that's expected to +ease the fix of the reloading, double clicking and every related +problem. Those fixes are not there yet! + +I just wanted to give this prototype a little testing before +adopting it. It was a 100Kb diff file! + +Jorge.- + + + +Re: [Dillo-dev]Internal release + +From: Sebastian Geerken - 2000-11-02 14:48 + +Hi! + +I finished a first version of dillo, with the new Dw integrated. It +compiles, and runs halfway, with thousands of warnings and criticals +(but no crash), furthermore some features are still missing (mouse +events, colors etc). + +Eric GAUDET wrote: +> I can't say I found it more stable yet on the multiple click on links +> side : still crashing. Wasn't it supposed to fix this ? (or is it that +> it's suppose to _ease_ the fixing of this ?) + +I wrote a test php3 page (I'll send it Eric, if you wish to), which +prints the current time (to check wheater reloading works), and has a +few delays in it (to simulate a slow connection), and tested it with +three versions: 0.2.4, 0.3.0-pre1, and 0.3.0-pre1 with the new Dw +integrated. Testing results have been always the same. + +Reloading after transmission is complete, works perfectly for all +versions, interrupting transmission by reloading didn't work correctly +in any version: 0.3.0-pre1 crashed, and 0.2.4 as well as 0.3.0-pre1 + +new Dw *both* did not crash, but displayed the old page (with the old +time). + +When debugging 0.3.0pre1, I found that the segmentation fault happens +in a_Dw_page_update_begin, with argument page == NULL. I wasn't able +to examine it more, since the stack was destroyed, but this reminds me +somehow of bug #77 (where there was somewhere a NULL pointer, and the +crash could be prevented by a simple check). When anchors work in the +new Dw, it could be a good idea to check whether bug #77 still arises. + +BTW, I tried to insert a few checks, but didn't get it run neither. + +Sebastian + + + +Re: [Dillo-dev]Internal release + +From: Sebastian Geerken - 2000-11-02 10:36 + +Jorge Arellano Cid wrote: +> [...] +> Sebastian: you can use this version in your effort to integrate +> the new Dw (or if you prefer, you can wait the testing news). +> Anyway, from Dw's perspective, changes to the interface are +> pretty minimal!) + +Ok, I'll integrate it into 0.3.0. (Should not be too hard to patch it +into any version.) + +> -- +> +> Sean: +> +> > Jorge, would you like for this to happen after Sebastian's +> > Dw changes? +> +> Yes, please wait until Sebastian integrates the new Dw. +> An entry in dillorc to disable FONT processing looks OK to +> me. (FONT tag is still a tricky issue: please be careful). + +I suppose, Sean's changes are mainly in the Html module, and since +there aren't much changes in the interface of DwPage, that should not +matter. + +Anyway, after integration, there will be still much to do, my current +plan is: +1. integration (will not take too much time), then +2. add missing features, and +3. bugs fixing, optimization, comments etc. + +I could send you a unfinished version after 2, which will be stable, +with defined interfaces, but still a bit buggy and slow. + +Sebastian + + + +RE: [Dillo-dev]Internal release + +From: Eric GAUDET - 2000-11-02 03:53 + +-- En reponse de "[Dillo-dev]Internal release" de Jorge Arellano Cid, +le 01-Nov-2000 : +> +> Hi! +> +> I just uploaded dillo-0.3.0-pre1 to the sourceforge server. +> This internal release is mainly intended for testing. If it +> proves to be at least as stable as 0.2.4, it will be the base for +> 0.3.0 release. +> + +I can't say I found it more stable yet on the multiple click on links +side : still crashing. Wasn't it supposed to fix this ? (or is it that +it's suppose to _ease_ the fixing of this ?) + +> Those of you that feel interested, please download it and let +> me know what you think about it (compared with 0.2.4). I'd +> appreciate your comments, specially if new BUGs arise. +> +> Most probably 0.3.0 will be this code-base plus a few patches, +> and a couple of weeks later 0.3.1 will integrate the rest of the +> patch queue. +> + +I'll update the Html.testsuite indications when 0.3.1 comes out then. + +----------------------------------- +Eric GAUDET +Le 02-Nov-2000 a 12:44:29 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Internal release + +From: Sean 'Shaleh' Perry - 2000-11-02 02:48 + +> +> Sean: +> +> > Jorge, would you like for this to happen after Sebastian's +> > Dw changes? +> +> Yes, please wait until Sebastian integrates the new Dw. +> An entry in dillorc to disable FONT processing looks OK to +> me. (FONT tag is still a tricky issue: please be careful). +> + +will wait for Sebastian then. Gives me some time for some other touch ups. + + + +[Dillo-dev]Internal release + +From: Jorge Arellano Cid - 2000-11-01 16:43 + +Hi! + + +I just uploaded dillo-0.3.0-pre1 to the sourceforge server. +This internal release is mainly intended for testing. If it +proves to be at least as stable as 0.2.4, it will be the base for +0.3.0 release. + +Those of you that feel interested, please download it and let +me know what you think about it (compared with 0.2.4). I'd +appreciate your comments, specially if new BUGs arise. + +Most probably 0.3.0 will be this code-base plus a few patches, +and a couple of weeks later 0.3.1 will integrate the rest of the +patch queue. + +Source code location: + +http://dillo.so....net/dillo-0.3.0-pre1.tgz + +-- + +Sebastian: you can use this version in your effort to integrate +the new Dw (or if you prefer, you can wait the testing news). +Anyway, from Dw's perspective, changes to the interface are +pretty minimal!) + +-- + +Sean: + +> Jorge, would you like for this to happen after Sebastian's +> Dw changes? + +Yes, please wait until Sebastian integrates the new Dw. +An entry in dillorc to disable FONT processing looks OK to +me. (FONT tag is still a tricky issue: please be careful). + + +Jorge.- + + diff --git a/old/oldmail/200012.txt b/old/oldmail/200012.txt new file mode 100644 index 0000000..d692502 --- /dev/null +++ b/old/oldmail/200012.txt @@ -0,0 +1,2938 @@ +[Dillo-dev]ALT attribute in `img' tag + +From: Livio Baldini Soares - 2000-12-27 20:17 + +Hi all! + +Recently I've inserted bug #116, to support ALT attributes in `img' +tags. Starting out the code, I realized that some of the needed +changes would go in dw_page.c and possibly html.c. Well I just read in +Allan's News, that Sebastian is planning to release his new Dw... + +Sebastian, have you done anything about the ALT attribute? And if +not should I wait a while for you to release what your doing before +trying to support ALT? + +best regards, + +-- +Livio + + + +[Dillo-dev]dillo-0.3.1 + +From: Jorge Arellano Cid - 2000-12-27 17:54 + +Surprise! + + +dillo-0.3.1 is ready for download (sourceforge is back :) + +Enjoy +Jorge.- + + + +[Dillo-dev]Window geometry (get_size fix and new dillorc option) + +From: Livio Baldini Soares - 2000-12-26 06:04 + +Hi guys, + +I've recently joined gtk list at gtk-list@gn..., and learned the +proper way of finding out a window's dimension. I was getting: +window->allocation.width +window->alloction.height + +in the patch I sent to make a new windows the same as parent +one. Seems that the "right" way to do it is calling +`gdk_window_get_size()`. I've already sent a patch to Jorge fixing +this up.. sorry guys. + +While I was on that "theme", I started to think about making an +option in dillorc for initial geometry size, because the first thing I +do when I open Dillo, is resize it... + +So that's what I've done. But I'm not sure the patch is good, +specially the string manipulations I've done to extract width and +height. The patch is at (I'm not sending it attached since it's +5k == 130 lines long): +http://www.linux.ime.usp.br/~livio/dillo/geometry_pref.diff + +The sintax in your dillorc, should be something like: + +> geometry="800x600" + +The patch changes the following files: + +dillorc: added comments and the above example +commands.c: changes the window size method to `gdk_window_get_size()', +like described abouve. +dillo.c: changed window initialization to get the preference size. +prefs.c: humm... did it! Look at my string stuff to see if I'm doing +it right +prefs.h: added +> #define DW_GEOMETRY_DEFAULT_WIDTH 640 +> #define DW_GEOMETRY_DEFAULT_HEIGHT 550 + +and `width' and `height' in struct _DilloPrefs. + +That's all... hope you like it (I did, don't have to keep resizing +dillo no more!) + +best regards, + +-- +Livio + + + +Re: [Dillo-dev]Entity parsing in links + +From: Eric GAUDET - 2000-12-25 17:10 + +-- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Jorge +Arellano Cid, le 24-Dec-2000 : +> I'll reply this post even though I know some posts hasn't +> arrived to my inbox (Is anyone else losing emails from the list?) +> + +I received Livio's replies to Sam before Sam's messages a couple of +times a few days ago. + +---------------------------------------- +Eric GAUDET +Le 26-Dec-2000 a 02:08:48 +"I remember Y1K, every abacus had to get another bead" +---------------------------------------- + + + +[Dillo-dev]Dillo Weekly News + +From: adc - 2000-12-24 23:12 + +Hi, the latest Dillo Weekly News has been posted. +You can find it at +http://www.shark.pwp.blueyonder.co.uk/news/news231200.html +please note that the links to the archives aren't filled in yet as I can't +get connected to the sourceforge site, it looks like sadly the problems at +sourceforge are continuing, I will fill them in as soon as possible. + + +-- +adc + + + +Re: [Dillo-dev]Entity parsing in links + +From: Jorge Arellano Cid - 2000-12-24 00:57 + +Hi, + +I'll reply this post even though I know some posts hasn't +arrived to my inbox (Is anyone else losing emails from the list?) + + +> On Sat, Dec 23, 2000 at 09:33:39AM -0300, Jorge Arellano Cid wrote: +> > +> > * When HTML (4.0 or 4.1) was reformulated as a SGML +> > application, the entities-parsing problem sprung-in. It wasn't +> > there until this point. SGML say they MUST be parsed. And the URL +> > rfc says that characters MUST be escaped according to the context +> > in which they're used. +> > So, URLs may have entities in them, and we should parse +> > them. +> +> Uh, no. URLs don't have entities in them, it's attributes (SGML sense) that +> have entities. Parsing entities in URLs would be a dire mistake. + +Once again: + +URLs don't have entities (as the URI/URL rfc say), but when +dealing with: + + - 2000-12-23 21:27 + +Jorge Arellano Cid writes: +> +> Hi, +> +> It seems I'm missing some emails from the list :( + +That's bad... You can always read from the archives: +http://www.geocrawler.com/lists/3/SourceForge/702/0/ Call me +suspicious, but I do that sometimes to check that I'm getting all +email. + +> I haven't seen this one (and some others) until quoted later. +> Sourceforge warned us that the mailing list was going to be moved +> with the respective downtime and glitches; just hope this not to +> continue... + +This was about a fix for bug #71 I +made. (http://www.linux.ime.usp.br/~livio/dillo/bug_71.diff) + + + +> +> Well, I have the FTP-plugin code here in my machine, and is +> time to put some work on it. The problem I face is that my todo +> list is always bigger than the time I have, so the only solution +> is to work on a priority basis. + +Uhh... and I was *"almost"* finishing mine... (about 10% done ;-) +That's ok, I learned A LOT about Dillo's IO system! + +> I know some of you may have noticed that there're three BUGs in +> the bug-track (taken by me) that haven't had any progress in the +> past weeks. They were scheduled, but I spent lots of time fixing +> patches; please help me by designning & reviewing your patches +> carefully before submitting them, there's no better thing for a +> maintainer to receive than a clean patch that's just a skim away +> from integration. + +No stress man! 8^) +Just for curiosity, what types of mistakes come up? What kind of +reviewing to you wish us to perform to make your work easier? (I mean, +what are the most common errors?) +What I do is after making a patch, get a clean copy from CVS and apply +my patch to it, and see if everything ok... besides always strinving +to maintain clean codes. + + +best regards, + +-- +Livio + + + +Re: [Dillo-dev]Entity parsing in links + +From: Sam Dennis - 2000-12-23 20:30 + +On Sat, Dec 23, 2000 at 05:59:46PM -0200, Livio Baldini Soares wrote: +> Jorge Arellano Cid writes: +> > +> > Hi everyone! +> +> Howdy! +> +> +> +> > So, URLs may have entities in them, and we should parse +> > them. +> > +> > +> > This problem is BUG#114. +> +> Well in that case, a possible patch is at: +> http://www.linux.ime.usp.br/~livio/dillo/entity_parse_in_url.diff +> +> Humm. I've been thinking about this patch, and what it does is parse +> entities in ALL attributes strings. Does anybody know if THAT's +> correct or is entity parsing only allowed in URL's? (Don't mean to +> start another polemic ;-) + +Not specific to URLs at all, honestly! It is specific to attributes +containing literal character data, though, although we don't actually deal +with any others yet, I think. + +> +> bye! +> +> -- +> Livio +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Entity parsing in links + +From: Sam Dennis - 2000-12-23 20:16 + +On Sat, Dec 23, 2000 at 01:14:10AM -0200, Livio Baldini Soares wrote: +> Eric GAUDET writes: +> > -- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio +> > Baldini Soares, le 23-Dec-2000 : +> +> + + + +> PS: Just for the hell of it, I'm sending in a patch against today's +> 0.3.1 version that enables entity parsing in attributes... +> +> best regards to all, +> +> **************************************************************** +> --- dillo/src/html.c Fri Dec 22 23:45:10 2000 +> +++ dillo.new/src/html.c Sat Dec 23 00:50:21 2000 +> @@ -2484,10 +2484,14 @@ static gint Html_match_attr(const char * +> * 0 if value is bigger than datasize +> * (This code is complex, but avoids a second pass over the value --Jcid) +> */ +> -static gint Html_get_attr_value(const char *tag, gint tagsize, +> +static gint Html_get_attr_value(const gchar *old_tag, gint old_tagsize, +> char *data, gint datasize) +> { +> - gint i; +> + gint i, tagsize; +> + gchar *tag; +> + +> + tag = Html_parse_entities((gchar *)old_tag, old_tagsize); +> + tagsize = strlen(tag); +> +> if (tag[0] == '"'|| tag[0] == '\´ ) { +> /* copy to end quote or to datasize */ +> @@ -2502,6 +2506,8 @@ static gint Html_get_attr_value(const ch +> if (i == tagsize - 1 && i >= 1 && tag[i - 1] == '/') +> i--; +> } +> + +> + g_free(tag); +> +> if ( i < tagsize && i < datasize ) { +> *--data = '\0'; + +A bit messy, that would replace entites throughout the entire tag, which is +not desirable as not even every type (although we treat them the same for +now) of attribute allows entities. + +It would likely work in all cases (use of an ampersand elsewhere in tags +would be extremely uncommon, even though it is allowed), but that's not the +point. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Entity parsing in links + +From: Livio Baldini Soares - 2000-12-23 19:59 + +Jorge Arellano Cid writes: +> +> Hi everyone! + +Howdy! + + + +> So, URLs may have entities in them, and we should parse +> them. +> +> +> This problem is BUG#114. + +Well in that case, a possible patch is at: +http://www.linux.ime.usp.br/~livio/dillo/entity_parse_in_url.diff + +Humm. I've been thinking about this patch, and what it does is parse +entities in ALL attributes strings. Does anybody know if THAT's +correct or is entity parsing only allowed in URL's? (Don't mean to +start another polemic ;-) + +bye! + +-- +Livio + + + +Re: [Dillo-dev]Entity parsing in links + +From: Sam Dennis - 2000-12-23 19:59 + +On Sat, Dec 23, 2000 at 09:33:39AM -0300, Jorge Arellano Cid wrote: +> +> * When HTML (4.0 or 4.1) was reformulated as a SGML +> application, the entities-parsing problem sprung-in. It wasn't +> there until this point. SGML say they MUST be parsed. And the URL +> rfc says that characters MUST be escaped according to the context +> in which they're used. +> So, URLs may have entities in them, and we should parse +> them. + +Uh, no. URLs don't have entities in them, it's attributes (SGML sense) that +have entities. Parsing entities in URLs would be a dire mistake. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +Re: [Dillo-dev]Entity parsing in links + +From: Jorge Arellano Cid - 2000-12-23 13:02 + +Hi everyone! + + +Once upon a time ;-) there was BUG#95 (Entities parsing within +URLs) and now there's BUG#114 (basically the same), and a lot of +email and doc-research had been done. + +The fact is somewhat complicated and although I explained it +before, when re-reading my post I found it less clear to follow +than when writing it. +I hope this new explanation to be better... + + +* The URL (URI) RFCs don't say a word about entities. The only +escaping mechanism allowed there is hexadecimal (i.e. %xx +sequences). So according to this source, they MUST NOT be parsed. + +* Up to HTML 3.2 this wasn't an issue, so no clue was found +here (AFAIK). + +* When HTML (4.0 or 4.1) was reformulated as a SGML +application, the entities-parsing problem sprung-in. It wasn't +there until this point. SGML say they MUST be parsed. And the URL +rfc says that characters MUST be escaped according to the context +in which they're used. +So, URLs may have entities in them, and we should parse +them. + + +This problem is BUG#114. + + +Jorge.- + + + +RE: [Dillo-dev]Bug #71 + +From: Jorge Arellano Cid - 2000-12-23 13:02 + +Hi, + +It seems I'm missing some emails from the list :( +I haven't seen this one (and some others) until quoted later. +Sourceforge warned us that the mailing list was going to be moved +with the respective downtime and glitches; just hope this not to +continue... + +> -- En reponse de "[Dillo-dev]Bug #71" de Livio Baldini Soares, le +> 23-Dec-2000 : +> > Oh, since I've looked though all the IO code carefully, I was +> > thinking of adding a FTP handler in Dillo... do we have an interest +> > for adding this support? Is there any other method that anyone wants +> > supported? (Should I spend my time doing this stuff, or does anyone +> > think there are more "pressing" issues to finish first?). +> +> Adding ftp would be very nice and is a short term to-do. IMHO a decent +> web browser have to provide http:, file: and ftp: protocols. + +Well, I have the FTP-plugin code here in my machine, and is +time to put some work on it. The problem I face is that my todo +list is always bigger than the time I have, so the only solution +is to work on a priority basis. + +I know some of you may have noticed that there're three BUGs in +the bug-track (taken by me) that haven't had any progress in the +past weeks. They were scheduled, but I spent lots of time fixing +patches; please help me by designning & reviewing your patches +carefully before submitting them, there's no better thing for a +maintainer to receive than a clean patch that's just a skim away +from integration. + +Sincerely +Jorge.- + + + +[Dillo-dev][ANN] Html.testsuite updated + +From: Eric GAUDET - 2000-12-23 09:29 + +Hi all, +assuming today's cvs version is the official v0.3.1, I tested it +against the Html.testsuite and updated the testsuite accordingly. + +http://www.rti-zone.org/dillo/ + +---------------------------------------- +Eric GAUDET +Le 23-Dec-2000 a 18:27:38 +"I remember Y1K, every abacus had to get another bead" +---------------------------------------- + + + +RE: [Dillo-dev]Bug #71 + +From: Eric GAUDET - 2000-12-23 07:28 + +-- En reponse de "[Dillo-dev]Bug #71" de Livio Baldini Soares, le +23-Dec-2000 : +> Oh, since I've looked though all the IO code carefully, I was +> thinking of adding a FTP handler in Dillo... do we have an interest +> for adding this support? Is there any other method that anyone wants +> supported? (Should I spend my time doing this stuff, or does anyone +> think there are more "pressing" issues to finish first?). +> + +Adding ftp would be very nice and is a short term to-do. IMHO a decent +web browser have to provide http:, file: and ftp: protocols. + +---------------------------------------- +Eric GAUDET +Le 23-Dec-2000 a 16:23:20 +"I remember Y1K, every abacus had to get another bead" +---------------------------------------- + + + +[Dillo-dev]Bug #71 + +From: Livio Baldini Soares - 2000-12-23 07:08 + +Hi there, + +I started to track down bug #71 today. It's the one that when you +have a HTML as the source of an image then that HTML title gets the +window's title. + +I spent more than an hour going over IO/MIME/Callback +code... Congratulations on whoever made this IO system, it's pretty +nice! Ok, then I finally found out what the problem was. After we make +the image request, when the document arrives there is a MIME lookup to +see which callback to use to handle the incoming stuff. If we have an +HTML then it's classified as text/html, which is ok. + +But the problem is that mime already calls text/html callback, which +is `a_Html_text()' (html.c). And then that will set the callback to +`Html_callback' and start "rendering" the HTML in the page (but we +don't see anything expect for the window's title changing), and we +were only expecting an image... + +The solution I've implemented is to verify in `a_Html_text' is the +DilloWeb->flags is actually a WEB_RootUrl, if it's not just bail out. + +For you guys that are "Dillo-oldies", is there anything wrong in +what I'm proposing? Should I initialize `html' in that function, waste +some time/space, but cleanly exit, or return NULL, saving that +time/space, but get a GTK_CRITICAL_ASSERT warning? Right now I chose +the first option. + +The patch is really small (3 lines of code), you can get at: +http://www.linux.ime.usp.br/~livio/dillo/bug_71.diff +but I'm sending it below. + +Oh, since I've looked though all the IO code carefully, I was +thinking of adding a FTP handler in Dillo... do we have an interest +for adding this support? Is there any other method that anyone wants +supported? (Should I spend my time doing this stuff, or does anyone +think there are more "pressing" issues to finish first?). + + +Here is the patch against 0.3.1 version (CVS 22/December/2000): +********************** +diff -pru dillo/src/html.c dillo.new/src/html.c +--- dillo/src/html.c Fri Dec 22 23:45:10 2000 ++++ dillo.new/src/html.c Sat Dec 23 04:17:18 2000 +@@ -72,6 +72,13 @@ Dw *a_Html_text(const char *Type, void * +DilloWeb *web = P; +DilloHtml *html = Html_new(web->bw); + ++ if (!(web->flags & WEB_RootUrl)) { ++ /* Asked for non-RootUrl (image or other mime), and got an ++ text/html MIME type... just bail out and save our skin. */ ++ *Call = a_Cache_null_client; ++ return html->dw; ++ } ++ +*Data = (void *) html; +*Call = (CA_Callback_t) Html_callback; + +*************************** + + +best regards, + +-- +Livio + + + +Re: [Dillo-dev]Entity parsing in links + +From: Livio Baldini Soares - 2000-12-23 03:14 + +Eric GAUDET writes: +> -- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio +> Baldini Soares, le 23-Dec-2000 : + + +> +> That's not true at all : urls don't have entities parsing mecanism. The +> only parsing for urls is escaping with % HEX HEX. '&' is a reserved +> character for separating 'name=value' blocks in an url. +> Unfortunatly, a few sites use entities in their urls, and some browsers +> (nestcape at least) allow this (but netscape's entities parsing is +> admitedly broken). +> This issue have already been discussed a few weeks ago in the list, +> please read the archives for more details + +Oops your right! Really sorry about that. There are two messages in the +archive concerning that, seems that this was a deleted "bug" (#95): + +http://www.geocrawler.com/archives/3/702/2000/11/0/4658162/ +http://www.geocrawler.com/archives/3/702/2000/11/0/4701809/ + +I should of read the archives... I think I assumed the Sourceforge +wouldn't be wrong in making HTML... + +Jorge, when you have time, please delete bug #114 (the one I've +inserted). + +By the way, since version 0.3.1 is out, do you strip out the bugs +with smileys on them (the `done` fixes)? Or do you keep them on for a +while, so everyone knows hows Dillo's developing? + +PS: Just for the hell of it, I'm sending in a patch against today's +0.3.1 version that enables entity parsing in attributes... + +best regards to all, + +**************************************************************** +--- dillo/src/html.c Fri Dec 22 23:45:10 2000 ++++ dillo.new/src/html.c Sat Dec 23 00:50:21 2000 +@@ -2484,10 +2484,14 @@ static gint Html_match_attr(const char * +* 0 if value is bigger than datasize +* (This code is complex, but avoids a second pass over the value --Jcid) +*/ +-static gint Html_get_attr_value(const char *tag, gint tagsize, ++static gint Html_get_attr_value(const gchar *old_tag, gint old_tagsize, +char *data, gint datasize) +{ +- gint i; ++ gint i, tagsize; ++ gchar *tag; ++ ++ tag = Html_parse_entities((gchar *)old_tag, old_tagsize); ++ tagsize = strlen(tag); + +if (tag[0] == '"'|| tag[0] == '\´ ) { +/* copy to end quote or to datasize */ +@@ -2502,6 +2506,8 @@ static gint Html_get_attr_value(const ch +if (i == tagsize - 1 && i >= 1 && tag[i - 1] == '/') +i--; +} ++ ++ g_free(tag); + +if ( i < tagsize && i < datasize ) { +*--data = '\0'; +******************************************************** + +-- +Livio + + + +[Dillo-dev]0.3.1 release + +From: Jorge Arellano Cid - 2000-12-23 02:01 + +Hi, + +I tryed to make a new release today(dillo-0.3.1), but +sourceforge servers didn't work. They claim to be under DDOS +atacks and it seems to be true :-) + +I'll try again tomorrow. The new version is in the CVS though. + +Jorge.- + + + +Re: [Dillo-dev]Entity parsing in links + +From: Eric GAUDET - 2000-12-23 01:40 + +-- En reponse de "Re: [Dillo-dev]Entity parsing in links" de Livio +Baldini Soares, le 23-Dec-2000 : +> +> Sam Dennis writes: +>> On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares +>> wrote: +> +> +> +>> > +>> > And that's exactly what Dillo sends, but Netscape, p.e, parses +>> > `&' into a `&'. So what is the correct action to perform? Is +>> > Dillo +>> > wrong or is Sourceforge wrong? +>> > +> +>> We're wrong, according to the specifications, character entities are +>> allowed +>> in attributes, and therefore '&' *must* be used in place of just +>> '&'. +>> +>> It's not just links, it's all string attributes. +>> +> + +That's not true at all : urls don't have entities parsing mecanism. The +only parsing for urls is escaping with % HEX HEX. '&' is a reserved +character for separating 'name=value' blocks in an url. +Unfortunatly, a few sites use entities in their urls, and some browsers +(nestcape at least) allow this (but netscape's entities parsing is +admitedly broken). +This issue have already been discussed a few weeks ago in the list, +please read the archives for more details + +> Thanks for looking this up Sam! +> +> I've put in the bug in the bug-track, it's bug #114. I've already +> assigned it to me ;^) I'll get to it after Christmas probably. +> +> PS: Jorge, how you doing with 0.3.1 version? Will it come out +> before +> Christmas? Hope so! +> +> best regards to all, +> +> -- +> Livio +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +----------------------------------- +Eric GAUDET +Le 23-Dec-2000 a 10:36:02 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Entity parsing in links + +From: Livio Baldini Soares - 2000-12-23 00:09 + +Sam Dennis writes: +> On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares wrote: + + + +> > +> > And that's exactly what Dillo sends, but Netscape, p.e, parses +> > `&' into a `&'. So what is the correct action to perform? Is Dillo +> > wrong or is Sourceforge wrong? +> > + +> We're wrong, according to the specifications, character entities are allowed +> in attributes, and therefore '&' *must* be used in place of just '&'. +> +> It's not just links, it's all string attributes. +> + +Thanks for looking this up Sam! + +I've put in the bug in the bug-track, it's bug #114. I've already +assigned it to me ;^) I'll get to it after Christmas probably. + +PS: Jorge, how you doing with 0.3.1 version? Will it come out before +Christmas? Hope so! + +best regards to all, + +-- +Livio + + + +Re: [Dillo-dev]Entity parsing in links + +From: Sam Dennis - 2000-12-22 21:30 + +On Fri, Dec 22, 2000 at 01:07:40AM -0200, Livio Baldini Soares wrote: +> Hi yall, +> +> I'm not sure this is a Dillo bug yet, so that's why I haven't added +> it to the bug-track. Does any one know if entities (like >   +> &) are supposed to be parsed in links (). +> +> I was browsing through Dillo's CVS, looking in the Changelog, at: +> http://cvs.so....net/cgi-bin/cvsweb.cgi/dillo/ChangeLog?cvsroot=dillo +> +> And I clicked on `annotate` for revision 1.19, then I got an +> error. If you look at that page's source you can see that the link is: +> annotate +> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +> +> And that's exactly what Dillo sends, but Netscape, p.e, parses +> `&' into a `&'. So what is the correct action to perform? Is Dillo +> wrong or is Sourceforge wrong? +> +> best regards, +> +> -- +> Livio +> +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +We're wrong, according to the specifications, character entities are allowed +in attributes, and therefore '&' *must* be used in place of just '&'. + +It's not just links, it's all string attributes. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]Entity parsing in links + +From: Livio Baldini Soares - 2000-12-22 03:07 + +Hi yall, + +I'm not sure this is a Dillo bug yet, so that's why I haven't added +it to the bug-track. Does any one know if entities (like >   +&) are supposed to be parsed in links (). + +I was browsing through Dillo's CVS, looking in the Changelog, at: +http://cvs.so....net/cgi-bin/cvsweb.cgi/dillo/ChangeLog?cvsroot=dillo + +And I clicked on `annotate` for revision 1.19, then I got an +error. If you look at that page's source you can see that the link is: +annotate +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +And that's exactly what Dillo sends, but Netscape, p.e, parses +`&' into a `&'. So what is the correct action to perform? Is Dillo +wrong or is Sourceforge wrong? + +best regards, + +-- +Livio + + + +Re: [Dillo-dev]Modularization(?) in Dillo + +From: Livio Baldini Soares - 2000-12-18 17:17 + +Hi Eric, + +Eric GAUDET writes: +> I've been thinking about that some times ago. What I wanted to do is to +> make a single bookmars menu attached the menubar of each browser +> window, but it seems to be impossible to attach a menu more than once +> in gtk, right ? + +Yes that's right! That's the whole problem with the bookmark menu +issue. You can't attach the same menubar to more than one menu... the +solution will have to be to create a new menubar widget... ok. But +current `Bookmarks_goto_bookmark` (the callback from choosing a +particular bookmark menuitem), sees if the selected widget is equal to +the first created one... that won't work. A fix for this would be to +pass the widget's index from `DilloBookmark bookmark[]`. + +But then we get another problem, we also need the browserwindow, or +else we won't know which *bw should we give to a_Nav_push(). + +So we need to pass the callback two arguments, but GTK only supports +callbacks with one argument (actually two, but the first you don't +choose, it's always the GTK_OBJECT which generated the event +signal). The solution GTK recommends for this (which is the obvious +one), is to create a struct with the desired fields and pass a pointer +to the struct. + +That's what I'm doing now (actually, I'm not since I'm in the middle +of final exams and they're *killing* me...), but I'll get to it at the +end of this week. That's why I'm was asking about where to place the +struct. + +So does `put it in bookmark.c` win? + +PS: What about the make new window the same size as the current one? +Did you finally get to resolving that? + +see yall, + +-- +Livio + + + +RE: [Dillo-dev]Modularization(?) in Dillo + +From: Eric GAUDET - 2000-12-18 12:09 + +I've been thinking about that some times ago. What I wanted to do is to +make a single bookmars menu attached the menubar of each browser +window, but it seems to be impossible to attach a menu more than once +in gtk, right ? + +-- En reponse de "[Dillo-dev]Modularization(?) in Dillo" de Livio +Baldini Soares, le 18-Dec-2000 : +> +> Hi all, +> +> I'm working on bug #110 (the bookmarks menu not appearing in +> new window) and was checking for the best way to fix this. I figured +> that all have to create a struct with a pointer to a menuitem (or an +> array index) and a pointer to the bw, and pass that struct to the +> callback (it really doesn't matter for now). What I want to get to, +> is +> where should I put (define) this new struct? +> +> I've seen that DilloBookmark is defined in browser.h, but should it +> be there at all? Because that's a struct that has no interest for the +> other modules, not even BrowserWindow, it is only used in +> bookmark.c. Since no other module should know, or need to know, what +> is a DilloBookmark, I suggest we take it out of browser.h and put it +> in bookmark.h (and I even dare say bookmark.c). And the struct that +> I'll create? I guess it should go in bookmark.c, since it is not +> interesting for other modules including bookmark.h to know? Or should +> I put it in bookmark.h, for cleanliness sake? +> + +I'll go for everything in bookmark.c, since it's not needed outside. + +----------------------------------- +Eric GAUDET +Le 18-Dec-2000 a 21:05:24 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Cookies + +From: Eric GAUDET - 2000-12-18 12:04 + +-- En reponse de "Re: [Dillo-dev]Cookies" de Livio Baldini Soares, le +18-Dec-2000 : +>> How to +>> manage persistant cookies, what kind of power the user should have +>> over +>> them, including, of course, denial of cookies, etc. +> +> +... +> Netscape 6, for example, has a type of "cookie manager", where you +> can define a rule (accept always, accept never) for each separate +> URL. I thought it very good. So I enabled cookies from sourceforge +> and +> disabled for the rest of the world... +> +> I would like Dillo to have something similar, a "cookie manager" +> with flexible rules for accepting/denying cookies for diferent +> sites. Maybe this manager could be integrated as a plugin... +> +> Any ideas? +> + +That would be very nice. What about a cookierc (text) file containing +all the rules (each line being a rule for an URL). I volunteer to code +a plugin for the manager (once the cookierc specs are decided). + +----------------------------------- +Eric GAUDET +Le 18-Dec-2000 a 20:59:06 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Modularization(?) in Dillo + +From: Livio Baldini Soares - 2000-12-18 11:15 + +Hi all, + +I'm working on bug #110 (the bookmarks menu not appearing in +new window) and was checking for the best way to fix this. I figured +that all have to create a struct with a pointer to a menuitem (or an +array index) and a pointer to the bw, and pass that struct to the +callback (it really doesn't matter for now). What I want to get to, is +where should I put (define) this new struct? + +I've seen that DilloBookmark is defined in browser.h, but should it +be there at all? Because that's a struct that has no interest for the +other modules, not even BrowserWindow, it is only used in +bookmark.c. Since no other module should know, or need to know, what +is a DilloBookmark, I suggest we take it out of browser.h and put it +in bookmark.h (and I even dare say bookmark.c). And the struct that +I'll create? I guess it should go in bookmark.c, since it is not +interesting for other modules including bookmark.h to know? Or should +I put it in bookmark.h, for cleanliness sake? + +bye yall, + +-- +Livio + + + +Re: [Dillo-dev]Cookies + +From: Livio Baldini Soares - 2000-12-18 10:47 + +Hello Sam, + +Sam Dennis writes: +> I seem to remember someone mentioning haved worked on, or at least having +> thought about, cookies in dillo. I'd like to bring it up again, as this +> seems like a good time to start thinking about implementing them. How to +> manage persistant cookies, what kind of power the user should have over +> them, including, of course, denial of cookies, etc. + + +I personally really dislike cookies. I only accept them when they're +really necessary for some service (like when `logging in` at +Sourceforge's web site). I would really like a finer control over +ccokies than what Netscape 4.X gives me. + +Netscape 6, for example, has a type of "cookie manager", where you +can define a rule (accept always, accept never) for each separate +URL. I thought it very good. So I enabled cookies from sourceforge and +disabled for the rest of the world... + +I would like Dillo to have something similar, a "cookie manager" +with flexible rules for accepting/denying cookies for diferent +sites. Maybe this manager could be integrated as a plugin... + +Any ideas? + +-- +Livio + + + +[Dillo-dev]A few answers + +From: Jorge Arellano Cid - 2000-12-17 17:48 + +Hi, + +Dillo 0.3.1 is almost ready for a release; most probably by +December 22. It is a very nice upgrade, you'll appreciate... +In the mean time, SourceForge made the move to their new +servers, but the download counters problem remain :( Just checked +a few projects and no one got their file-hits right... Anyway, +dillo-0.3.1 will be there before Christmas. + + +Jorge.- + +----- +[Bruno] + +> I have a rather small monitor, and for my taste dillo +> displays text in a fontsize too small. It would be nice if +> you could change fonts/fontsizes in the ~/.dillo/dillorc file. +> ... + +Sometime ago Sebastian suggested a font-factor; that's a very +good idea to implement. A single number in dillorc that scales +font sizes (a flash skim through html.c showed that you'll have +to search some hard coded font-size numbers within the code to +implement it; not hard though!). + +----- +[Cookies] + +J=F6rgen submitted a patch a long time ago. It's not complete and +the unimplemented part is the cookie sending one. This patch has +been procrastinated due to: + +a) priorities +b) the url-passing scheme needs a new implementation + +Currently, POST and GET do some url-string hacking to get their +data to the IO part, and then to the remote server. Cookies need +to send some information too, and the same happens with +authentication. + +This is basically a matter of defining a Url structure and +passing it to a lot of functions. The complex part is that +there're lots of functions that expect a URL string, there're +several workarounds, some hacks also, and last but not the least: +dillo's code is very tight and dependent on URLs (they are used +as primary Keys in the cache for instance, and several decisions +are being made in the URL passing chain from one module into +another). + +Ah, there's also the problem of URL normalization in between. + +---- +[Patches] + +Please send them with 'diff -pru', that makes it easier for me. + + + +[Dillo-dev][ANN] Dillo-pluginsin PHP + +From: Eric GAUDET - 2000-12-17 13:50 + +Hi folks, +I just posted "a Dillo-plugin for using PHP to build applications using +the Dillo-plugins mechanism. This is really a wrapper to PHP compiled +as CGI, not an Apache module. (enclosed in the archive a sample php +application, and hints for compiling PHP)" + +http://www.rti-zone.org/dillo/ + +----------------------------------- +Eric GAUDET +Le 17-Dec-2000 a 22:45:21 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Fontsize + +From: Bruno Widmann - 2000-12-15 15:27 + +Hi, + +I have a rather small monitor, and for my taste dillo +displays text in a fontsize too small. It would be nice if +you could change fonts/fontsizes in the ~/.dillo/dillorc file. + +I had a look around the sources, and found that in html.c +the fontsize seems to be hardcoded. + +in Html_page_check there is + +font.size = 12; + +and in Html_tag_open_h there is + +gint sizes[] = {24, 18, 18, 14, 12, 10} + +which sets fontsizes for text under

-

+ +I have allready played around with prefs.c/h and it's quite +simple to add config items there so that you can change these values +via dillorc. + +But I don't know if this is the "right way" to do it. +Or maybe thers something else planed for fonthandling? If it's ok +to add these values to the configfiles i could submit a patch. + + + +[Dillo-dev]Cookies + +From: Sam Dennis - 2000-12-14 22:37 + +I seem to remember someone mentioning haved worked on, or at least having +thought about, cookies in dillo. I'd like to bring it up again, as this +seems like a good time to start thinking about implementing them. How to +manage persistant cookies, what kind of power the user should have over +them, including, of course, denial of cookies, etc. + +-- +Sam Dennis + +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]SourceForge downtime + +From: Jorge Arellano Cid - 2000-12-14 12:24 + +Hi, + +There's a downtime scheduled to Friday December 15, it will +affect: Web site, CVS, mailing lists and mailing aliases. + +You have been warned... :-) + +Jorge.- + + + +[Dillo-dev]Bug #109 tag + +From: Jorge Arellano Cid - 2000-12-12 12:17 + +Hi, + + +Please note that when making the bug-track entry for FONT +tags, Livio did the right thing (according to the rules); even +more, when he finally found out that there was someone else +working on it, he apologized gently (even though it was not his +fault), and offered his help. --meus parabêns pro senhor. + +BUGs are not owned: there's a explicit recommendation to those +interested in helping the developer that first took them, to +contact him and to offer any help. + + +Jorge.- + + + +Re: [Dillo-dev]Bug #109 ( tag) + +From: Livio Baldini Soares - 2000-12-12 05:55 + +Sean 'Shaleh' Perry writes: + +> > +> > Would you like me to change the bug-track entry so that the being +> > `worked on` field points to you? (Of course, you can do it yourself if +> > you want, it's but #109). +> > +> +> I thought I was marked somewhere on that. WIll make sure I own 109. + +Ok, I've done this for you. I put in the `Being worked by:` field +with value "shaleh@vi...". You can change that or add more info in +the volunteering page (http://dillo.so....net/Dvolunteer.html). + +Sorry again for the mix-up, + +best regards, + +-- +Livio + + + +[Dillo-dev]html tag implementations + +From: Sean 'Shaleh' Perry - 2000-12-11 21:25 + +Would anyone who has added support for an unsupported tag please mail me your +patches. I see several new bugs where people claim to have implemented +some new tag. I would like to integrate that work with my own. + + + +RE: [Dillo-dev]Bug #109 ( tag) + +From: Sean 'Shaleh' Perry - 2000-12-11 21:24 + +> +> I think Sean made a patch for all font stuff. He should have made a +> bugtrack entry too :-/ +> + +yeah, i should use the bug engine more, I just hate it, sorry Jorge. It does +not order the items at all, I can not easily find new items for old ones, or do +many other things I am used to from a bug tracking system. Why not use the +sourceforge one? Or something, anything. + + + +Re: [Dillo-dev]Bug #109 ( tag) + +From: Sean 'Shaleh' Perry - 2000-12-11 21:20 + +> +> Would you like me to change the bug-track entry so that the being +> `worked on` field points to you? (Of course, you can do it yourself if +> you want, it's but #109). +> + +I thought I was marked somewhere on that. WIll make sure I own 109. + + + +RE: [Dillo-dev]Bug #109 ( tag) + +From: Sean 'Shaleh' Perry - 2000-12-11 21:19 + +On 10-Dec-2000 Livio Baldini Soares wrote: +> Hi yall, +> +> I've included bug #109 into the bug-track, when I was looking at a +> teacher's page when I noticed that some colored text wasn't colored +>:-( So I checked the src/html.c, func Html_tag_open_font, and I saw: +> + +hmm, how many mails have I sent saying I had font (and most other font +touching) tags working quite nicely (-: Would you mind sending me your +patch so I could integrate your work. + +Jorge asked me to keep my html cleanups until after Sebastian releases his Dw +widget. + + + +Re: [Dillo-dev]Bug #96 + +From: Livio Baldini Soares - 2000-12-10 20:30 + +Hellos, forgot to mention something... + +Livio Baldini Soares writes: + + + +> The patch is in: +> http://www.linux.ime.usp.br/~livio/dillo/new_window_same_size.diff +> +> If you want I can e-mail it to you personally, so I wouldn't +> generate extar traffic on the list. Hope this helps you on what you're +> doing. + +This pacth is to be applied against current CVS version +(Dec-10). Jorge uploaded a new version (yesterday), and those changes +are necessary for this patch to work. + + +that's all, bye, + +-- +Livio + + + +Re: [Dillo-dev]Bug #109 ( tag) + +From: Livio Baldini Soares - 2000-12-10 18:32 + +Eric GAUDET writes: +> -- En reponse de "[Dillo-dev]Bug #109 ( tag)" de Livio Baldini +> Soares, le 10-Dec-2000 : +> > Hi yall, +> > +> > I've included bug #109 into the bug-track, when I was looking at a +> > teacher's page when I noticed that some colored text wasn't colored +> >:-( So I checked the src/html.c, func Html_tag_open_font, and I saw: +> > +> +> I think Sean made a patch for all font stuff. He should have made a +> bugtrack entry too :-/ + +Oops! Sorry for the mix up, you're right. I checked the mailing +archives and seems like Sean has being doing font stuff for some time +now... Sorry abou that Sean! + +Would you like me to change the bug-track entry so that the being +`worked on` field points to you? (Of course, you can do it yourself if +you want, it's but #109). + +I'll discontinue with my version, since your's is probably much +better, and you have been in to this much longer than I. + +> +> About SIZE, each browser is free to render it as it likes, so your idea +> of multiplying by 4 is good. +> Let me propose something : make new dillorc parameters for these (say +> default_font_size and default_font_step) +> + +Good idea. + +> As for FACE, Jorge doesn't like it, and I agree with him on this point +> : html is for client-side rendering, the author is not supposed to use +> his own fonts. We choosed (so far) to ignore it. + +Hum... strange. But surelly Dillo will have an option +`Render it just like the author intended to be', will it not? I mean, +it's really nice to have a very flexible rendering system, so the +client can do all his heart's will, but sometimes the client's heart's +is willing to see it like the author intended... and then you'd be +taking away flexibility... + +*yeah my english sucks! Did you understand a word I said?* + +> (BTW number 1 to 7 is 7 font sizes, not 8 ;-) + +Oops... I guess I should catch up on my sleep :-o + + +> > checking if all chars are valid hex digits [0-9a-fA-F]. Any body +> > know someway better to do this? +> > +> +> If you check first for named colors, then your hex 6-digits scan, +> you're good. +> ("0x" is not in HTML specs, only "#") + +Like Homer would say: "DOPE" (tap on the head!) Of course! + + +bye all, + +-- +Livio + + + +Re: [Dillo-dev]Bug #96 + +From: Livio Baldini Soares - 2000-12-10 18:18 + +Hi Eric, + +before anything I would like to say that I really don't want to +start arguments or flames or anything like that... I just want to help +you out, like you've always done for me. So sorry if I still disagree +with you, but I think this kind of stuff is worth discussing so that +we ALL can learn from (specially me, who knows too little...). If I'm +being a pest about this issue, let me know and I'll drop it, ok? + +With that said let's get to more interesting issues ;-) + +Eric GAUDET writes: + + + +> > What do you need this info (focused window) for? Could you use the +> > solution I've made for your problem too? Maybe I can help out... +> > +> +> Well, that's actually why I made this proposal : your solution can't be +> applied to my problem ;-) +> But I though mine would solve both (and probably more) at the same time, +> so it can have some good in it. +> +> (since your want more infos, I needed to know the size and position of +> the window that was clicked to open a new window and smartly adjust its +> geometry) + +Ok, I've thought a little bit more about this and I think that both +solutions are ok. But my solution seems easier for bug #96 and your +solution to the "opening new same sized window" problem (or maybe +not... read on). + +Let me see if I understand correctly this problem ... To use my +solution on to implement this you'll have to connect a signal to a +callback with two arguments: (1 = the clicked link, 2= the clicked bw, +to extract the size). But this is already handled in +Dw_page_handle_event... and then it calls +a_Commands_open_link_nw_callback with the bw that was CLICKED by the +user... (isn't this what you wanted?). So, theoretically, all you'd +have to is get the size from the `bw` in +a_Commands_open_link_nw_callback and pass it to a modified +a_Interface_new_browser_window which takes the size as arguments... + +Sorry, if am still missing the point... but it still seems needless +to have the last_clicked_bw. I think it is totally feasible to use my +solution... hum, let me see... + + + +Ok, I have a patch here that opens new windows the same size as the +parent window the call came from (wether from the menu `New Window`, +or clicking with button 2, or clicking with button 3 and selecting +`Open Link in new window`). Are looking to this something similar? + +The patch is in: +http://www.linux.ime.usp.br/~livio/dillo/new_window_same_size.diff + +If you want I can e-mail it to you personally, so I wouldn't +generate extar traffic on the list. Hope this helps you on what you're +doing. + +> +> I understand, and I would agree on this. Most of the time. But real life +> coding made me a "get_the_big_picture_and_you_won't_have_to_waste_your_ +> time_fixing_many_similar_problems" kind of guy ;-) + +Yeah, you might be right, I lack lots of expericence. I'm still a +newbie at this open source programming stuff, and you guys are my +"gurus". So don't ever hesitate to say that I'm doing something wrong, +or being too stubborn, chances are, I'm completely wrong about what +I'm saying. + +later dude! + +-- +Livio + + + +RE: [Dillo-dev]Bug #109 ( tag) + +From: Eric GAUDET - 2000-12-10 08:00 + +-- En reponse de "[Dillo-dev]Bug #109 ( tag)" de Livio Baldini +Soares, le 10-Dec-2000 : +> Hi yall, +> +> I've included bug #109 into the bug-track, when I was looking at a +> teacher's page when I noticed that some colored text wasn't colored +>:-( So I checked the src/html.c, func Html_tag_open_font, and I saw: +> + +I think Sean made a patch for all font stuff. He should have made a +bugtrack entry too :-/ + +> 1) `size=absolute' or `size=[+-]relative'. +> What W3 says is that we should accept 8 font sizes (numbered from +> 1-7), but in Dillo we have more granularity, ending up with more +> numbered sizes (at least 24, which is in the

tag). So how should +> I deal with this? In my patch I multiply html size value by 4, giving +> us Dillo size value... of course this isn't the "right" way to +> convert from font numbering. Anybody has any ideas? +> + +About SIZE, each browser is free to render it as it likes, so your idea +of multiplying by 4 is good. +Let me propose something : make new dillorc parameters for these (say +default_font_size and default_font_step) +As for FACE, Jorge doesn't like it, and I agree with him on this point +: html is for client-side rendering, the author is not supposed to use +his own fonts. We choosed (so far) to ignore it. +(BTW number 1 to 7 is 7 font sizes, not 8 ;-) + +> 2) a_Color_parse issues... +> +> There are two issues which I've encountered: +> +> i) color="Aqua" doesn't resolve to anything! It should resolve to +> "aqua" == 0x00ffff, shouldn't it? This issue seems to me like a +> Dillo bug... To fix this I changed all words to their lower-case +> representation. I did this with: +>> for (i = 0; i < strlen(subtag); i++) +>> subtag[i] = tolower(subtag[i]); +> Is there a better/more efficient way of doing this? +> + +Unfortunatly not. + +> ii) color="ff00aa" +> To read a color as a hex number Dillo requires a "0x" or "#" +> prefix, but I've found many html's with just color="56abf3", or +> something like this. Currently, to fix this, I did something +> TOTALLY wrong! Just checked if (strlen(subtag) == 6). To only +> real fix which I thought of was to run over `subtag' string +> checking if all chars are valid hex digits [0-9a-fA-F]. Any +> body +> know someway better to do this? +> + +If you check first for named colors, then your hex 6-digits scan, +you're good. +("0x" is not in HTML specs, only "#") + +----------------------------------- +Eric GAUDET +Le 10-Dec-2000 a 16:03:49 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Bug #109 ( tag) + +From: Livio Baldini Soares - 2000-12-10 05:43 + +Hi yall, + +I've included bug #109 into the bug-track, when I was looking at a +teacher's page when I noticed that some colored text wasn't colored +:-( So I checked the src/html.c, func Html_tag_open_font, and I saw: + +#if 0 + +#endif +Html_push_tag(...) + +Does anyone know/remember why this was commented out? Well it didn't +work anyway, so I started to see if I could get the tag +working. After sometime I got a pretty good working version (it still +has a small render bug, but I think it's pretty much working). I +checked http://www.w3.org to see the qualifiers for the tag , they are: +`face', `size' and `color'. So those are the one I've implemented. + +The current patch is in: +http://www.linux.ime.usp.br/~livio/dillo/font_tag.diff + +It will corretly render HTML like: +http://www.rti-zone.org/dillo/Html.testsuite/color.html +or +http://www.linux.ime.usp.br/~livio/dillo/font-test.html + + +The patch will change two files: src/html.c and src/colors.c. +There is are two small issues that are pending so I can get this patch +100% done. + +1) `size=absolute' or `size=[+-]relative'. +What W3 says is that we should accept 8 font sizes (numbered from +1-7), but in Dillo we have more granularity, ending up with more +numbered sizes (at least 24, which is in the

tag). So how should +I deal with this? In my patch I multiply html size value by 4, giving +us Dillo size value... of course this isn't the "right" way to convert +from font numbering. Anybody has any ideas? + +2) a_Color_parse issues... + +There are two issues which I've encountered: + +i) color="Aqua" doesn't resolve to anything! It should resolve to +"aqua" == 0x00ffff, shouldn't it? This issue seems to me like a +Dillo bug... To fix this I changed all words to their lower-case +representation. I did this with: +> for (i = 0; i < strlen(subtag); i++) +> subtag[i] = tolower(subtag[i]); +Is there a better/more efficient way of doing this? + +ii) color="ff00aa" +To read a color as a hex number Dillo requires a "0x" or "#" +prefix, but I've found many html's with just color="56abf3", or +something like this. Currently, to fix this, I did something +TOTALLY wrong! Just checked if (strlen(subtag) == 6). To only +real fix which I thought of was to run over `subtag' string +checking if all chars are valid hex digits [0-9a-fA-F]. Any body +know someway better to do this? + +I think that's all my doubts for now... and ideas/critics/support +are always supported, + +bye, + +-- +Livio + + + +Re: [Dillo-dev]Bug #96 + +From: Eric GAUDET - 2000-12-10 03:41 + +-- En reponse de "Re: [Dillo-dev]Bug #96" de Livio Baldini Soares, le +09-Dec-2000 : +>> BrowserWindow *topmost_bw; +>> This variable is updated in dw_page.c, GDK_BUTTON_PRESS event. +>> +>> Any thought ? +> +> Humm.. this could work too. But I think this solution is a little +> more complex. + +I don't quite see how a 3 lines-patch can be complex. + +> Not necessarilly, in all window managers/systems, does +> clicked == focused. I think we might have a long and tiresome battle +> to get all the cases where the window is focused, so the topmost_bw +> is always correct and accurate. + +Hum, you noticed the question mark. We could change the name for +last_clicked_bw, if you think it's less confusing. +What we really need is CLICKED, so our popup menus (which can be used +only when _click_ing) know what bw we're talking about. + +> I don't know, but it seems too tricky to get this to work out, and +> maybe "unclean"... +> + +*cough* +"unclean" is a dangerous concept : it makes you think the code is more +important that the application. +"maybe unclean" is even worse : it makes you think the same while +admitting you didn't investigate the problem. + +(don't get me wrong : I'm not advocating dirty-but-cool hacks, I'm more +like Jorge's "don't over-optimize" topic) + +> What do you need this info (focused window) for? Could you use the +> solution I've made for your problem too? Maybe I can help out... +> + +Well, that's actually why I made this proposal : your solution can't be +applied to my problem ;-) +But I though mine would solve both (and probably more) at the same time, +so it can have some good in it. + +(since your want more infos, I needed to know the size and position of +the window that was clicked to open a new window and smartly adjust its +geometry) + +> Sorry for the mean critic... but I think college has made me into a +> "avoid_global_variables,_they_will_give_you_trouble_in_the_future" +> kind of guy ;-) +> + +I understand, and I would agree on this. Most of the time. But real life +coding made me a "get_the_big_picture_and_you_won't_have_to_waste_your_ +time_fixing_many_similar_problems" kind of guy ;-) + +> best regards, +> + +likewise, +----------------------------------- +Eric GAUDET +Le 10-Dec-2000 a 12:23:43 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Comments + +From: Eric GAUDET - 2000-12-10 03:18 + +-- En reponse de "[Dillo-dev]Comments" de Jorge Arellano Cid, le +09-Dec-2000 : +> you'll notice in the Changelog that almost no patch got clean into +> the sources, I had to rework most of them; please be more careful +> before submitting. +> + +Can you tell us what are the common errors, so we can be more careful ? + +> ---- +> Checkboxes [Eric] +> +> Have you checked what the Specs say about it? +> + +VALUE is a requiered attribute for CHECKBOXES (and RADIO). We're talking +here about how to deal with faulty tag missing requiered attributes, +which is not uncommon in web pages. +Browsers have a different behavior : +- Dillo sends "name=" +- Netscape and Amaya send "name=on" +- Opera sends nothing (but renders the checkbox, which is the worse case +IMHO) +- (IE not tested) + +PS: another FORM related issue : the SUBMIT button's value is not +POSTed by Dillo. It should. + +----------------------------------- +Eric GAUDET +Le 10-Dec-2000 a 12:02:55 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Re: Comments (more on GIF bug 98) + +From: Livio Baldini Soares - 2000-12-10 02:15 + +Livio Baldini Soares writes: +> Jorge Arellano Cid writes: + + + +> > ---- +> > GIF spec [Livio]: +> > +> > http://www.w3.org/Graphics/GIF/spec-gif89a.txt +> > (thanks for checking) +> +> Oh, should of looked in w3! Thanks, I'll check it later. +> + +Well I check it out. It *seems* to me that the coordinates from the +Logical Screen Descriptor are in fact ignorable, but I'm not +absolutely sure. Here is the part that matters from the GIF +specification: + +************************************** +> 18. Logical Screen Descriptor. +> +> a. Description. The Logical Screen Descriptor contains the parameters +> necessary to define the area of the display device within which the +> images will be rendered. The coordinates in this block are given with +> respect to the top-left corner of the virtual screen; they do not +> necessarily refer to absolute coordinates on the display device. This +> implies that they could refer to window coordinates in a window-based +> environment or printer coordinates when a printer is used. +************************************** + +Virtual-screen? Printer? It seems to me that it's ignorable, and we +can really just rely on the coordinates from the Image +Descriptor. Here's the spec info on the Image Descriptor: + +************************************** +> 20. Image Descriptor. +> +> +> a. Description. Each image in the Data Stream is composed of an Image +> Descriptor, an optional Local Color Table, and the image data. Each +> image must fit within the boundaries of the Logical Screen, as defined +> in the Logical Screen Descriptor. +> +> The Image Descriptor contains the parameters necessary to process a +> table based image. The coordinates given in this block refer to +> coordinates within the Logical Screen, and are given in pixels. This +> block is a Graphic-Rendering Block, optionally preceded by one or more +> Control blocks such as the Graphic Control Extension, and may be +> optionally followed by a Local Color Table; the Image Descriptor is +> always followed by the image data. +************************************* + +Well can anybody who's a better english speaker and has more image +knowledge tell me if I'd doing something wrong in ignoring the Logical +Screen Descriptor's coordinates? I think it's okay, specially after +reading this spec and reading xloadimage-4.1 source code (it ignores +it too). + +If there are no objections, then the patch I have completely fixes +bug #98.. just have to clean it up a bit before sending it in... + +Any feedback is appreciated, best regards to all, + +-- +Livio + + + +Re: [Dillo-dev]Comments + +From: Livio Baldini Soares - 2000-12-09 19:47 + +Jorge Arellano Cid writes: +> +> Hi, + +Hi Jorge! + +Nice work. I've seen that you've updated CVS versions twice after +the 0.3.0 release. That's really nice, cause we can see dillo change +dinamically and not in big jumps like before, hope you keep this +up. If you do intend to keep updating CVS with certain frequency, then +may I suggest a dillo-cvs-log@so...? I don't know how it's +done, but I've seen other projects do this, and I thoght it really +neat. Everytime someone (you) makes a CVS check-in, then the list +(dillo-cvs-log) receives an e-mail with the the list of modified files +and your log message, what do you think? If you like the idea, but +don't know how to do it, I can try and read the sourceforge manuals +for you and see if I discover something. + + + +> ---- +> GIF spec [Livio]: +> +> http://www.w3.org/Graphics/GIF/spec-gif89a.txt +> (thanks for checking) + +Oh, should of looked in w3! Thanks, I'll check it later. + +> +> Ah, have you finished BUG#96? The bug-track shows 90% and its +> already integrated into my source tree! + +It's not 90% anymore ;-) Yes I have finished! I put 90% cause I was +waiting to hear back from anybody to see if my bug fix was good +enough... but thinking it over for a week now, I couldn't come up with +anything better design, so I think it's good enough. I haven't changed +anything so the version you integrated is probably up-to-date. + + +> ---- +> Weekly news [Allan] +> +> Huh? :-) + +Yeah, where are you Allan? Hope that everything's okay with +you... (or hope you're travelling trough the world, meeting lots of +beatiful girls, and that's why you're kind of gone). I miss those +weekly news! + +bye yall, + +-- +Livio + + + +[Dillo-dev]Comments + +From: Jorge Arellano Cid - 2000-12-09 19:17 + +Hi, + + +Well, it seems that dillo is getting better and improving +faster than before. The patch queue is also being flooded at a +higher rate and from different persons. I'm very happy with this, +and also spent a lot of time integrating the patches; you'll +notice in the Changelog that almost no patch got clean into the +sources, I had to rework most of them; please be more careful +before submitting. + +Maybe that's due to what I call "the rush effect": when a +developer gets into a coding task and hasn't made the entry in +the bug track, he gets eager to finnish before any one else does. +Please avoid this situation (Yes, I received repeated patches, +and had to make some bug-track-entries myself to stop it). + +On the other hand, the big patch queue was very interesting +and after integration has made --no doubt!-- a better dillo; +Thanks everybody. + +Yes, there's enough material for making a new release, I just +want to test it some more, add a few improvements, wait for +sourceforge's counters to start working again and it'll be there. + + +Jorge.- + + +---- +GIF spec [Livio]: + +http://www.w3.org/Graphics/GIF/spec-gif89a.txt +(thanks for checking) + +Ah, have you finished BUG#96? The bug-track shows 90% and its +already integrated into my source tree! + + +---- +Checkboxes [Eric] + +Have you checked what the Specs say about it? + + +---- +Weekly news [Allan] + +Huh? :-) + + + +Re: [Dillo-dev]Bug #96 + +From: Sebastian Geerken - 2000-12-09 18:03 + +Livio Baldini Soares writes: +> [...] +> Humm.. this could work too. But I think this solution is a little +> more complex. Not necessarilly, in all window managers/systems, does +> clicked == focused. I think we might have a long and tiresome battle +> to get all the cases where the window is focused, so the topmost_bw is +> always correct and accurate. I don't know, but it seems too tricky to +> get this to work out, and maybe "unclean"... + +Not necessary. There are simpler ways to check which window is +focused, but in this case, you indeed want to get the last window the +user had clicked into, not the focus window (and a window manager +*does not need* to focus this window). Another way would be to store +the browser window belonging to the page into the popup menu, just +before popping it up. + +However, I'd prefer Livius' implementation, there is really no need +to make the code kludgier as needed just to save little memory +(compared to the memory anyway allocated for a browser window). + +> What do you need this info (focused window) for? Could you use the +> solution I've made for your problem too? Maybe I can help out... +> +> Sorry for the mean critic... but I think college has made me into a +> "avoid_global_variables,_they_will_give_you_trouble_in_the_future" +> kind of guy ;-) + +The college had reasons for it. ;-) + +Sebastian + + + +[Dillo-dev]About bug #98 (GIF especification?) + +From: Livio Baldini Soares - 2000-12-09 17:02 + +Hi all! + +Since I went trough the png test suite, I couldn't help noticing the +http://www.rti-zone.org/dillo/Html.testsuite/badgif.html, where +there's a gif that's not drawn correctly. I've found the problem and +made a patch to fix this, but I'm not sure I'm doing the "correct" +thing to fix it... but my fix doesn't seem to break any other GIFs. + +The problem is that gif->width and gif->height are supposed to be +read from 2 distinct places. From the Logical Screen Descriptor +(where: +gif->Width = LM_to_uint(buf[0], buf[1]); +gif->Height = LM_to_uint(buf[2], buf[3]); +) + +*and* from the Image Descriptor +(where: +gif->Width = LM_to_uint(buf[4], buf[5]); +gif->Height = LM_to_uint(buf[6], buf[7]); +) + +Currently Dillo is only reading it's width and height from the +Logical Screen Descritor. I've checked sources from gif2png and +xloadimage (xview), and they seem to respect only the Image Descriptor +width and height, and almost ignore and coordinates from Logical +Screen Desc (which is kind of strange). So what I've done is just +that, I don't call a_Dicache_set_parms from within Gif_get_descriptor, +but call it with the "correct" values from Gif_do_img_desc. This seems +to work fine with all GIF's and should work with all GIF's are +open-able(?) with xloadimage. (oh the patch is at: +http://www.linux.ime.usp.br/~livio/dillo/bad_gif.diff). + +But I want to make sure I'm doing the correct thing... So does +anybody know where I can find an GIF especification? Or like GIF-RFC? +IS there a GIF especification at all for public eyes? If I could get +one, them I could really make sure that my patch is full proof. + +best regards, + +-- +Livio + + + +Re: [Dillo-dev]Bug #96 + +From: Livio Baldini Soares - 2000-12-09 16:08 + +Eric GAUDET writes: +> Hey Livio, + +Hi Eric! + +> +> -- En reponse de "[Dillo-dev]Bug #96" de Livio Baldini Soares, le +> 01-Dec-2000 : +> > I started working on patch number 96. It was the bug that when +> > trying to `View Source` with multiple windows open, Dillo would +> > always get the last opened window and view that source, no matter on +> > what window we clicked. +> +> How did you eventually manage the problem ? + +Like I wrote in the previous e-mail, I've made each bw have it's own +menu_pop, i.e. make menu_pop a member of the struct +_BrowserWindow. This way the signal was corretly assigned to the right +bw. Personally, I think this is a clean fix, which doesn't require a +lot of rework, and seems to be robust. This way we don't have to worry +which is the focused or clicked window, since GTK deals corretly with +this when we connect the signal (right_button on bw -> open menu_pop). + +> I had a similar problem, needing to know what was the last clicked (== +> focused ?) window. The solution I used would help both of us, I think. I +> added a global variable in dillo.c : +> BrowserWindow *topmost_bw; +> This variable is updated in dw_page.c, GDK_BUTTON_PRESS event. +> +> Any thought ? + +Humm.. this could work too. But I think this solution is a little +more complex. Not necessarilly, in all window managers/systems, does +clicked == focused. I think we might have a long and tiresome battle +to get all the cases where the window is focused, so the topmost_bw is +always correct and accurate. I don't know, but it seems too tricky to +get this to work out, and maybe "unclean"... + +What do you need this info (focused window) for? Could you use the +solution I've made for your problem too? Maybe I can help out... + +Sorry for the mean critic... but I think college has made me into a +"avoid_global_variables,_they_will_give_you_trouble_in_the_future" +kind of guy ;-) + +best regards, + +-- +Livio + + + +RE: [Dillo-dev]Bug #96 + +From: Eric GAUDET - 2000-12-09 12:28 + +Hey Livio, + +-- En reponse de "[Dillo-dev]Bug #96" de Livio Baldini Soares, le +01-Dec-2000 : +> I started working on patch number 96. It was the bug that when +> trying to `View Source` with multiple windows open, Dillo would +> always get the last opened window and view that source, no matter on +> what window we clicked. + +How did you eventually manage the problem ? +I had a similar problem, needing to know what was the last clicked (== +focused ?) window. The solution I used would help both of us, I think. I +added a global variable in dillo.c : +BrowserWindow *topmost_bw; +This variable is updated in dw_page.c, GDK_BUTTON_PRESS event. + +Any thought ? + +----------------------------------- +Eric GAUDET +Le 09-Dec-2000 a 21:22:34 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Re: * + +From: Jorge Arellano Cid - 2000-12-06 00:48 + +Hi, + +> Eric GAUDET writes: +> +> > Do you still have this hash function ? I need one and I'm not sure mine +> > is that good. +> +> Doesn't glib include one? At least the header file suggests so. There +> are several function declarations named 'g_hash_table_*()'. So, this +> might be worth looking into. + +I digged into my archive and didn't find them :( +(I surely had been so dissapointed that ...!) + +Anyway, I was using mph-1.2.tar.gz (22 Kb), an excellent +package for generating minimal perfect hashes. Once you find a +function, it can be tuned in steps and table size, very cool +stuff. I remember that I built a hash function for every +supported HTML tag in dillo, and tuned it to half the size and 2 +or three steps; it was faster than the binary search, sure (4% or +so), but the added complexity, was not worth the trouble. + + +Jorge.- + + + +Re: [Dillo-dev]Final PNG transparent, file URI and bug 107 + +From: Sebastian Geerken - 2000-12-05 10:19 + +Livio Baldini Soares writes: +> 2) +> Sometime ago I sent in a patch to correct, what I considered, a +> misbehaviour, but since nobody said anything (neither against or in +> favor), I'll ask again. When I type in the following in Dillo: +> +> /home/livio/ +> +> Dillo will then try to resolve http://home/livio/, but that isn't what +> I wanted him to do. Im my opinion Dillo should consider URL's starting +> with a '/' (slash) as a file request. What do you guys think? + +Yes, since '/' is not allowed in host names, I'd say this is a good +idea. + +Another idea: With all the plugins in future, how about a common +scheme based on regular expressions, configured by the user, e.g: + +/^ftp\.[[:alnum:]\.]+\// -> ftp:// (assuming that ftp server names +often begin with "ftp.") +/^[[:alnum:]\.]+\// -> http:// +/^\// -> file: +/^\(.+\)/ -> info: +/^\w+\(\w+\)$/ -> man: + +> I've made a patch to do exactly this. It's small, check it out at: +> http://www.linux.ime.usp.br/~livio/dillo/file.diff +> +> 3) +> I tried to reproduce bug #107, but I failed. If anyone on the list +> registered bug 107, could you please explain how to reproduce it, so I +> may that a llok at it? + +I didn't register it, but just try +http://download.so....net/dillo/dillo-0.3.0.tar.gz + +Sebastian + + + +RE: [Dillo-dev]Final PNG transparent, file URI and bug 107 + +From: Eric GAUDET - 2000-12-05 09:53 + +-- En reponse de "[Dillo-dev]Final PNG transparent, file URI and bug +107" de Livio Baldini Soares, le 05-Dec-2000 : +> 1) +> Just wanted to write to say I've completely finished the png +> transparency implementation. Including the gamma correction which I +> didn't implement in the previous patch. So with that I think that the +> PNG test suite on Eric's site is pretty much complete, or have I +> skipped something? +> + +This png test suite is the official png test suite. + +> 2) +> Sometime ago I sent in a patch to correct, what I considered, a +> misbehaviour, but since nobody said anything (neither against or in +> favor), I'll ask again. When I type in the following in Dillo: +> +> /home/livio/ +> +> Dillo will then try to resolve http://home/livio/, but that isn't +> what I wanted him to do. Im my opinion Dillo should consider URL's +> starting with a '/' (slash) as a file request. What do you guys +> think? +> +> I've made a patch to do exactly this. It's small, check it out at: +> http://www.linux.ime.usp.br/~livio/dillo/file.diff +> + +That's too bad dillo's having a different behavior when getting a URL +in the command line or in the nav bar. Should be the same. + +> 3) +> I tried to reproduce bug #107, but I failed. If anyone on the list +> registered bug 107, could you please explain how to reproduce it, so +> I may that a look at it? +> + +No negfault for me either. I think it's the same bug with interrupting +download again. I'm pretty sure whoever made this entry can't reproduce +it every time. +IMHO there should be a big warning on the bug insertion page +asking people to test _several_ time the how-to-reproduce method before +they submit. + +----------------------------------- +Eric GAUDET +Le 05-Dec-2000 a 18:40:59 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +Re: [Dillo-dev]Re: * + +From: Eric GAUDET - 2000-12-05 09:39 + +-- En reponse de "Re: [Dillo-dev]Re: *" de Livio Baldini Soares, le +05-Dec-2000 : +> Eric GAUDET writes: +>> I had a quick look at the sources, and I don't understand why +>> passing bw isn't enough for finding what page was clicked. +>> However, I know the bug is there : _I_ did the bugtrack entry ! +> +> Well I'll try to explain it in my bad english... +> +> Since there was only one (global) `menu_popup`, everytime a new +> window was opened the same menu_popup would be (re)initialized (in +> a_Menu_popup_new). In that initialization the Menu_add (to connect a +> signal to a callback function), would be written over with the new +> parameter (the new *bw). So when the signal (event) called the +> callback, it would send the latest *bw NOT the current *bw. +> +> Ummm, did it get any clearer, or just confused you more? +> +> bye, + +I think I'm begining to see the light ;-) What I understand now is when +registering a call-back, the parameter (bw) is registered too. I though +the parameter was updated according to the calling widget each time the +callback was invoked (&bw). +... I should really read this gkt book I bought a while ago ;-) + + +----------------------------------- +Eric GAUDET +Le 05-Dec-2000 a 18:33:54 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Final PNG transparent, file URI and bug 107 + +From: Livio Baldini Soares - 2000-12-05 02:32 + +Hello again, + +Since I'm crowding too much this list lately I'll send in a 3 in 1 +e-mail. Here goes my three topics: + +1) +Just wanted to write to say I've completely finished the png +transparency implementation. Including the gamma correction which I +didn't implement in the previous patch. So with that I think that the +PNG test suite on Eric's site is pretty much complete, or have I +skipped something? + +2) +Sometime ago I sent in a patch to correct, what I considered, a +misbehaviour, but since nobody said anything (neither against or in +favor), I'll ask again. When I type in the following in Dillo: + +/home/livio/ + +Dillo will then try to resolve http://home/livio/, but that isn't what +I wanted him to do. Im my opinion Dillo should consider URL's starting +with a '/' (slash) as a file request. What do you guys think? + +I've made a patch to do exactly this. It's small, check it out at: +http://www.linux.ime.usp.br/~livio/dillo/file.diff + +3) +I tried to reproduce bug #107, but I failed. If anyone on the list +registered bug 107, could you please explain how to reproduce it, so I +may that a llok at it? + +that's about all, see yall latter, + +-- +Livio + + + +Re: [Dillo-dev]Re: * + +From: Livio Baldini Soares - 2000-12-05 01:39 + +Eric GAUDET writes: +> -- En reponse de "[Dillo-dev]Re: *" de Jorge Arellano Cid, le +> 01-Dec-2000 : + + + + +> >> [BUG #96] +> > +> > I'll answer this one when I look up the patch code. I'm +> > interested cause a similar problem arises when trying to get the +> > link the mouse was over at click time (for "Save link as"). +> > +> +> I had a quick look at the sources, and I don't understand why passing bw +> isn't enough for finding what page was clicked. +> However, I know the bug is there : _I_ did the bugtrack entry ! + +Well I'll try to explain it in my bad english... + +Since there was only one (global) `menu_popup`, everytime a new +window was opened the same menu_popup would be (re)initialized (in +a_Menu_popup_new). In that initialization the Menu_add (to connect a +signal to a callback function), would be written over with the new +parameter (the new *bw). So when the signal (event) called the +callback, it would send the latest *bw NOT the current *bw. + +Ummm, did it get any clearer, or just confused you more? + +bye, + +-- +Livio + + + +Re: [Dillo-dev]Re: * + +From: Livio Baldini Soares - 2000-12-05 01:29 + +Hi Jorge, + +Jorge Arellano Cid writes: +> +> Hi! +> + + + +> +> Eric found a good solution by publishing pre-patches in his web +> site, maybe you can ask him for some space when necessary. + + +Ok, I agree that sometimes it can be annoying and waste of +bandwidght to have all patches attached to the list. I should of +thought of having my patches on a web page before :-( + +Here is a link to all the patches which I've made (or am currently +working on): + +http://www.linux.ime.usp.br/~livio/dillo/ + +It's my homepage from the University. It is REALLY slow, and +sometimes the University has it's backbone down and won't respond at +all. If anyone is trying to get a particular patch they can e-mail me +and ask, I'll be happy to provide it. + + + +> > [PNG transaparency] +> +> Please send me your last patch (when done) Livio. + +I've pretty much finished, and you can get it at: +http://www.linux.ime.usp.br/~livio/dillo/pang_transparency.diff + +But I will sent it to you personally. + + + +> > [BUG #96] +> +> I'll answer this one when I look up the patch code. I'm +> interested cause a similar problem arises when trying to get the +> link the mouse was over at click time (for "Save link as"). +> + +I've tried it out, and the patch I've made fixes the problem with +`Save link as...` too. The patch is here: + +http://www.linux.ime.usp.br/~livio/menu_pop.diff + + +that's about all... best regards, + +-- +Livio + + + +RE: [Dillo-dev]Re: * + +From: Rafael R. Sevilla - 2000-12-03 18:37 + + + + + +RE: [Dillo-dev]Re: * + +From: Eric GAUDET - 2000-12-03 16:42 + +he was talking about a minimal perfect hash function, not a hash +function robust for cryptography purposes. +However, I tested the the glib hash function for strings, and it's not +good _at_all_ : not near perfect (lots of collisions, any XOR-based +function is better). Almost unsuable. + +-- En reponse de "[Dillo-dev]Re: *" de Olaf Dietsche, le 03-Dec-2000 : +> Eric GAUDET writes: +> +>> Do you still have this hash function ? I need one and I'm not sure +>> mine +>> is that good. +> +> Doesn't glib include one? At least the header file suggests so. There +> are several function declarations named 'g_hash_table_*()'. So, this +> might be worth looking into. +> +> Regards, Olaf. +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> http://lists.so....net/mailman/listinfo/dillo-dev + +----------------------------------- +Eric GAUDET +Le 04-Dec-2000 a 01:38:50 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Re: * + +From: Olaf Dietsche - 2000-12-03 15:48 + +Eric GAUDET writes: + +> Do you still have this hash function ? I need one and I'm not sure mine +> is that good. + +Doesn't glib include one? At least the header file suggests so. There +are several function declarations named 'g_hash_table_*()'. So, this +might be worth looking into. + +Regards, Olaf. + + + +[Dillo-dev]just subscribed, dillo is faaaast :-) + +From: Olaf Grüttner - 2000-12-02 13:13 + +I just wanted to thank you guys. I recognize dillo being work in progress, +but is so fast it is wonderful and compared +to things like netscape 6 on linux it is lightning fast. + +can´t wait till tables are supported by dillo. + +keep up the good work!!! + +Olaf + +-- + + + +RE: [Dillo-dev]Re: * + +From: Eric GAUDET - 2000-12-02 01:32 + +-- En reponse de "[Dillo-dev]Re: *" de Jorge Arellano Cid, le +01-Dec-2000 : +> Eric found a good solution by publishing pre-patches in his web +> site, maybe you can ask him for some space when necessary. +> + +Sure :-) (any free web hosting will do, though) + +> The University told us that code optimization was a task to be +> undertaken by the compiler (mainly peephole opt.), the real world +> is different! +> + +I used to code demos in asm-68k, I must still have some in the blood ;-) + +> Finally, never try to over-optimize!!! +> + +right ! But don't stop until your done with sensible loops code. + +> Speed opt. is a highly tricky matter. For instance, what seems +> faster in theory doesn't always show on reality: sometime ago I +> was tunning a minimal perfect hash function for dillo, and I +> succeeded!, but profiling revealed that the gain over a simple +> binary search was around 2%, and the added complexity was +> impressive. +> + +Do you still have this hash function ? I need one and I'm not sure mine +is that good. + +> +>> [BUG #96] +> +> I'll answer this one when I look up the patch code. I'm +> interested cause a similar problem arises when trying to get the +> link the mouse was over at click time (for "Save link as"). +> + +I had a quick look at the sources, and I don't understand why passing bw +isn't enough for finding what page was clicked. +However, I know the bug is there : _I_ did the bugtrack entry ! + +----------------------------------- +Eric GAUDET +Le 02-Dec-2000 a 10:24:24 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +RE: [Dillo-dev]Re: * + +From: Sean 'Shaleh' Perry - 2000-12-01 21:44 + +>> Another thing, there was a comment in the header of a_Url_squeeze +>> made by Jorge, saying the he wasn't sure that it was necessary. Well I +>> checked APACHE and it's NOT necessary to squeeze the URL. I sent in a +>> request with a telnet to port 80, and sent an `GET /./FAQ/../ HTTP/1.0`, +>> and got the /index.html. Seems to work fine with both /../ and /./, +>> but I'm not sure if this is true to all HTTP servers. The only time +>> APACHE complains is when we send in a request for /FAQ/../../, APACHE +>> claims this is a BAD REQUEST, but the new a_Url_squeeze prevents +>> this +> + +if the function is trivial, it probably saves the server some work. plus I +wonder what IIS does with this? + +>> [Code optimization] +> +> Eric's suggestions can be very insightful. I just want to add +> my two-cents. +> +> The University told us that code optimization was a task to be +> undertaken by the compiler (mainly peephole opt.), the real world +> is different! +> + +one thing I was taught was to profile, profile, profile. There is a nice GNU +tool called gprof to help with this. You compile the app with profiling turned +on, run it, then run gprof on the output (gmon.out I think). You get a +function call tree, time spent in each, etc. Very useful. + + + +[Dillo-dev]Re: * + +From: Jorge Arellano Cid - 2000-12-01 20:16 + +Hi! + +As usual, here you'll find several answers (batch mode!) + +> Another thing, do you (or anybody +> else) have anything against sending patches to the list, so everyone +> can "pitch" in, and publically(?) discuss them. If not do you want me +> to CC: them to you, Jorge? + +I don't have an absolute answer for this question. +Cartainly, final-patches must be sent to me for revision and +inclusion, but those that can be considered as a "work in +progress" can be sent to the list for discussion. + +This mailing list has a reputation (gained over time) to be low +traffic and interesting, and I love it that way; maybe the best +way is hold patches while still polishing them and only request +some help or feedback when you really need it. Posting the patch +is a last resource, cause you always have the chance to send it +privately to the helping party. + +Eric found a good solution by publishing pre-patches in his web +site, maybe you can ask him for some space when necessary. + +> [...] +> I'll change the status to 100% in the bug-track when I get back net +> connection. Oh, and I'm NOT suppossed to put `done`, this is done by +> Jorge when he inserts the patch in the code (IF we agree the code is +> worth putting in), is this correct Jorge? + +Absolutely. + + +> Another thing, there was a comment in the header of a_Url_squeeze +> made by Jorge, saying the he wasn't sure that it was necessary. Well I +> checked APACHE and it's NOT necessary to squeeze the URL. I sent in a +> request with a telnet to port 80, and sent an `GET /./FAQ/../ HTTP/1.0`, +> and got the /index.html. Seems to work fine with both /../ and /./, +> but I'm not sure if this is true to all HTTP servers. The only time +> APACHE complains is when we send in a request for /FAQ/../../, APACHE +> claims this is a BAD REQUEST, but the new a_Url_squeeze prevents +> this + +Thanks for the info. + +BTW: Does anyone remember BUG#95? (Whether or not to parse +entities within URIs) I answered that sometime ago but, ....!!!, +my last research showed that although the URI RFC doesn't mention +entities, when the w3c guys decided to define HTML as SGML, +the entities parsing problem sprung-in, and the recomendation is +to parse them!!! (HTML 4.01 Appendix B 2.2). + +I don't if they changed the recommendation when they decided to +put-off SGML and defined XHTML as XML :-) + + +> [PNG transaparency] + +Please send me your last patch (when done) Livio. + + +> [Code optimization] + +Eric's suggestions can be very insightful. I just want to add +my two-cents. + +The University told us that code optimization was a task to be +undertaken by the compiler (mainly peephole opt.), the real world +is different! + +Some time ago I made some local vars optimizations that yielded +a bit more than a 100% percent speed gain!!!!! (with gcc :-). +When I exposed the problem to one of the gcc-tester's team, he +couldn't believe his eyes. + +Finally, never try to over-optimize!!! + +Speed opt. is a highly tricky matter. For instance, what seems +faster in theory doesn't always show on reality: sometime ago I +was tunning a minimal perfect hash function for dillo, and I +succeeded!, but profiling revealed that the gain over a simple +binary search was around 2%, and the added complexity was +impressive. + + +> [BUG #96] + +I'll answer this one when I look up the patch code. I'm +interested cause a similar problem arises when trying to get the +link the mouse was over at click time (for "Save link as"). + + + +Jorge.- + + + +Re: [Dillo-dev]Re: About bug #60 (transparency in PNG's) + +From: Eric GAUDET - 2000-12-01 09:29 + +-- En reponse de "Re: [Dillo-dev]Re: About bug #60 (transparency in +PNG's)" de Livio Baldini Soares, le 01-Dec-2000 : +> By the way, I also had forgotten to add a "composite" support, for +> when alpha value is between 0 (fully transparent) and 255 (totally +> opaque). I'm sending the new version, look at it and see if it's more +> 'decent' or is it still crappy? (Am sending it attached...) +> + +It's very nice. It's probably faster than the original code too. +BTW, testing for 0 and 255 is a very nice optimisation over +png_composite : as these values are more likely to be used, you avoid +calling a function. + +> Oh and I also checked the PNG test suite and compared against +> netscape 6 for Linux. The only thing that was different was the gamma +> correction. I guess there isn't any gamma correction with current PNG +> in dillo. Maybe I'll to do that some other time. Meanwhile, should I +> put such small problem in the bug-track, or should I leave it alone, +> hence it's "kind" of documented in the test suite? +> + +Isn't there a gamma-init function in pnglib ? +Anyway, IMHO we should all make more bugtrack entries, even for such +tiny problems, so we don't forget them. Jorge can always remove it if he +thinks it's not important. + +> I still have a doubt though. I currently left alone the outer for: +> for (i = 0; i < png->width; i++) { +> but just to acknowledge when to stop, cause I don't use `i` anywhere +> else. Do you see a better way to detect when png is over with. +> + +No, that's how it's done. Perhaps png->width can be calculated outside, +but it shouldn't matter much. +If it wasn't image processing (we're talking about hundred thousands +pixels, one loop for each pixel), I wouldn't suggest the following +(since i is not used) : +for ( i = png->width ; i ; i-- ) +;-))) + +Last thing : you've probably reviewed the gif decoding to learn how +transparency is delt with. Do you think the code is optimised enough ? + +ciao + +----------------------------------- +Eric GAUDET +Le 01-Dec-2000 a 18:13:57 +"Le verbe inexister ... inexiste !" +----------------------------------- + + + +[Dillo-dev]Bug #96 + +From: Livio Baldini Soares - 2000-12-01 04:21 + +Attachments: menu_pop.diff + +Hi! + +I started working on patch number 96. It was the bug that when +trying to `View Source` with multiple windows open, Dillo would always +get the last opened window and view that source, no matter on what +window we clicked. First I went to look for the source of the problem, +it appears to be the fact the the is only Menu_popup for all the +windows. And when we open a new window using +a_Interface_new_browser_window, we re-initilialize menu_popup, with: + +> menu_popup.menu = a_Menu_popup_new(bw); +> menu_popup.menu_over_link = a_Menu_popup_ol_new(bw); + +And in a_Menu_popup_new we add the callback for selecting View +Source, and all other Menu_popup entries. So for every new window, the +callback are changed to look up it's data from that window, ignoring +the possibility of other older windows... + +So I have thought up of two solutions, and for the first one I'm +sending in the patch which I've made (almost minimal changes to +current program): + +1) One solution is to have every window have it's own menu_popup. So +basically I changed struct _BrowserWindow to include a +DillowMenuPopup, and changed all ocurrences of menu_popup tp +bw->menu_popup. This is the solution I've implemented and am sending +the patch. + +2) The other soluion would involve more changes to current code, but +might be more economic. Instead of having each BrowserWindow have it's +own menu_popup like in (1), continue like current code, having a +global menu_poup, but use the browser_window[] Vector(? array?) index +to pass to the callback. So when the callback is called it checks, +somehow, from what window is the signal coming from and them access +the window using the browser_window[] array. I didn't like this idea +so much as it would make the code uglier and even though we would +economize a mune_popup per new window, we would create overhead to +find out from what window was the signal coming from and process that +information accordingly. + + +Any ideas/comments? I would really apreciate, since I still haven't +convinced myself I've chosen the right choice (or there may be +others...). + +Oh, and the patch is supposed to be applyied over the whole dillo +directory (from CVS), but will only affect: src/bookmark.c, +src/browser.h, src/commands.c, src/dw_page.c, src/interface.c, +src/menu.c. + +best regards to all, + +-- +Livio + + + +Re: [Dillo-dev]Re: About bug #60 (transparency in PNG's) + +From: Livio Baldini Soares - 2000-12-01 03:04 + +Attachments: png_transparent2.diff + +Gee, thanks, Eric! + +Very nice tips you gave on my patch (some of the stuff I already +knew but was too lazy/sleepy to get things out). Sorry about the +newbie code... but with all of your suggestions, now I think the patch +is looking good... + +By the way, I also had forgotten to add an "composite" support, for +when alpha value is between 0 (fully transparent) and 255 (totally +opaque). I'm sending the new version, look at it and see if it's more +'decent' or is it still crappy? (Am sending it attached...) + +Oh and I also checked the PNG test suite and compared against +netscape 6 for Linux. The only thing that was different was the gamma +correction. I guess there isn't any gamma correction with current PNG +in dillo. Maybe I'll to do that some other time. Meanwhile, should I +put such small problem in the bug-track, or should I leave it alone, +hence it's "kind" of documented in the test suite? + +Eric GAUDET writes: +> +> IMHO there's several problem with your calculations : + +;-) + +> +> 1) the strol part is very inefficient, but that's not a real problem +> because this code is _outside_ the loop. Anyway, here's how to do it : +> (strip all the sprintf) +> bg_blue = (prefs.bg_color0 & 0xFF; +> bg_green = (prefs.bg_color>>8) & 0xFF; +> bg_red = (prefs.bg_color>>16) & 0xFF; + +Yeah, this one I knew was really bad... + +> +> 2) The loop is _always_ the sensible part ! You _never_ want to allocate +> local variables like you did : +> for (...) { +> gint p,a; +> (some compiler may optimize this, but you never know) +> As a rule of thumb, it's better to allocate local variables at the +> begining of a function. +> + +I agree completely, loops are what makes the code have a higher +complexity, and everything that can, should be put outside of the +loop. + +> 3) If you really want to improve speed, do all calculation only once in +> local variables : i*3 is computed three times, it would be better to +> have calculated i3 = i*3 and use i3. (same with i*4 used twice). +> You could also have done i3 += 3 each loop, but on pentium-generation +> cpu (whatever the brand, ppc, arm, ...) multiplications and additions +> cost the same so it doesn't matter, and using i*3 is often more +> readable and more robust (not sensible to initiallisation). +> +> 4) Even better : look into a table is a calculation. png->linebuf[3*i] +> is actually *(png + linebuf + 3*i). +> You could have declared +> guchar *pl = png->linebuf; +> and in the loop : +> if (!a){ +> *(pl++) = bg_red; +> *(pl++) = bg_green; +> *(pl++) = bg_blue; +> } +> + +Liked this option (4) much more than 3. + +> The else part is basically the same, if a little more trickier, and you +> can get rid of the costy for() : I let it to you as an exercise ;-) +> (hint : row_num*png->rowbytes is ugly) + +Well... how is it now? Less uglier? + +I still have a doubt though. I currently left alone the outer for: +for (i = 0; i < png->width; i++) { +but just to acknowledge when to stop, cause I don't use `i` anywhere +else. Do you see a better way to detect when png is over with. + +> +> 5) Last : if(!a) is more complex than if(a) : invert the if/else. +> +> Hope this helps. + +Yes! This helps a lot! Thanks a bunch Eric. + +best regards, + +-- +Livio + + diff --git a/old/oldmail/200101.txt b/old/oldmail/200101.txt new file mode 100644 index 0000000..ce8a8fb --- /dev/null +++ b/old/oldmail/200101.txt @@ -0,0 +1,311 @@ +[Dillo-dev]Frames + +From: Sam Dennis - 2001-01-31 15:24 + +Apologies to anyone who's thinking of working on frames, but I've started. + +Expect patches Very Soon. + +-- +Sam Dennis +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]0.4.0 devel-branch + +From: Jorge Arellano Cid - 2001-01-29 23:55 + +-------------------------------------- +This message is from Sebastian Geerken +-------------------------------------- + +Hi! + +Just a few words: The most important task is now to make 0.4.0 +stable, but in future there will also be a few enhancements, in speed +and code structure (both esp. in dw_page.c). + +Livio, I tried to answer your question, but my mail got lost twice: +> Recently I've inserted bug #116, to support ALT attributes in `img' +> tags. Starting out the code, I realized that some of the needed +> changes would go in dw_page.c and possibly html.c. Well I just read in +> Allan's News, that Sebastian is planning to release his new Dw... +> +> Sebastian, have you done anything about the ALT attribute? And if +> not should I wait a while for you to release what your doing before +> trying to support ALT? + +There are the signal functions "enter_notify" and "leave_notify" +which should be used for this. Just insert your code into +Dw_image_enter_notify and Dw_image_leave_notify. + +Sebastian + +PS: Bugs No. 1002 and 1003 are no segfaults, I just forgot to change +the menus in the form. + + + +Re: [Dillo-dev]0.4.0 development branch + +From: Sam Dennis - 2001-01-29 18:29 + +On Sun, Jan 28, 2001 at 10:30:46AM -0300, Jorge Arellano Cid wrote: +> The new DwWidget will be the base for TABLE and FRAME support. +> +> +> Any questions?, just ask! + +Er, just one, really. How will it actually be easier to implement tables and +frames with the changes than without? + +-- +Sam Dennis +"The strstr() function finds the first occurrence of the substring needle in +the string haystack." + + + +[Dillo-dev]0.4.0 development branch + +From: Jorge Arellano Cid - 2001-01-28 13:36 + +Hi there! + + +It's been a long time without any posts, but dillo has +continued evolving silently! + +The good news is that finally the new widget set (DwWidget), +by Sebastian, is available from CVS. It is not yet the main +branch, but we're strongly working to that goal. Just review the +updated web site and you'll find the details. + +We need all our developing efforts concentrated in making this +new branch, as stable and featured as dillo-0.3.1 in order to +make a new release based upon it. + +The new DwWidget will be the base for TABLE and FRAME support. + + +Any questions?, just ask! + + +Jorge.- + + + +[Dillo-dev]New Dw + +From: Jorge Arellano Cid - 2001-01-11 16:29 + +Sebastian, + +Finally I get news from you!!! +(I know it is NOT your fault) + + +> Ok, this is the fourth trial. There are a some news: the new Dw is +> now up-to-date with dillo-0.3.1, + +Does it mean that it currently implements the same +functionallity? + +> including the changes in dw_page.c +> (esp. find text and image maps), and I ported the hruler and the +> bullet widget. + +Good. + +------------ + +> Hi Jorge, +> +> did you receive my mail from Dec 14 (which was already a copy of a +> mail sent at Dec 12)? I send it again, since I know you have had +> severe problems with your mail server. + +I never did receive one until now :( + +> ------ +> +> Hi Jorge, +> +> I've come to a point where the new Dw has a final interface, and is +> already usable enough (although buggy and a bit incomplete, and not +> very well tested), from outside (e.g. the html parser) as well as for +> someone who writes a new widget. Currently I'm reviewing the sources, +> adding comments and writing some documentation. I plan to make this +> state available for other dillo developers, together with comments +> about current bugs. + +Yes, documentation is a big need because it constitutes +everyone else's starting point. When you finish the documentation +it will be the right moment to try the integration. + +> [...] +> My changes outside of Dw are marginal, so coordination with the +> official release should be possible simply by patches. Dw has mostly +> been rewritten (except DwPage, but it was heavily modified), but I'll +> try to include relevant modifications on the old Dw into the new one, +> at every release (I won't regard the CVS versions). +> +> The reason I wrote this is the question "Tarball vs. CVS": I don't +> have experiences in using CVS and think that updating a tarball from +> time to time should work well enough. But I don't really prefer one +> of both. A further problem is the coordination of the further work, +> should e.g. the bug tracking engine be used? Anyway, I don't think +> that the problems will be that big, because the work will continue in +> a quite closed manner, until the Dw becomes part of the official +> release. + +Well, my plan for the integration/polishing process is to +freeze dillo development into a bux-fixing state (no new-feature +additions), and try to work out the new Dw until it supports the +same functionallity (or more) of the 0.3.1 release. + +Obviously we need the new-Dw to be potentially capable of +undertaking all the required functionallity before we start +merging. + +The idea behind this is to keep a single development branch (we +have little manpower and past experiences had shown that is +better to keep focused on a single tree...), and to emerge with a +new source tree that includes the new-Dw and also provides the +older features with at least the same stability degree that 0.3.1 +has now (that's the way I replaced the whole IO engine, the whole +cache system, and also the way the new internal layers got into +the code!). + +Once we start with this, we'll all be working the CVS tree +(You and I with write access), and you reviewing the patches (if +you accept, of course). + +On the coordination effort, I can easily set a new bug-track +for the CVS branch, so once we finish producing the 0.4.0 release +we can get back into the older one. + +Up to this point, the key questions are: + +Is the new Dw able to handle all the current functionallity? +Is the new-Dw potentially able to handle tables and frames? +Is it faster or slower than the current one? +Do you foresee any problems if we start now? +Is the documentation ready? +Do you feel like taking responsibility for patch reviewing and +integration for Dw related code, at least at this integration +stage? + + +Needless to say, I feel very motivated with this effort and I +only hope that our scarce, but very appreciated developers join +us in this big step! + + +Sincerely +Jorge.- + + + +[Dillo-dev]New bug-track + +From: Jorge Arellano Cid - 2001-01-10 23:36 + +Hi, + +I just finished porting the bug-track to python and moving it +to sourceforge; I hope this results in better response times for +everyone. + +You may experiment some problems due to intermediate network +caches. If you receive a message saying that the requested url +doesn't exist (for a cgi), a simple reload of the previous page +solves it! i.e. a single reload of the three links in Dbugtrack +will solve the problem forever. + +Unfortunately, dillo does not perform end-to-end reload +(BUG-64), so you'll need lynx or anyother to do the reloads. Once +this is done you can keep using dillo. + +BTW: Bug-64 is very easy to hack-fix (a few sprinkled lines), +but the plan is to fix the URL data-passing scheme with a view to +have the required basis to solve a bunch of related problems +(We are working with Livio on it). + + +Jorge.- + + + +RE: [Dillo-dev]jcid's nettaxi email account + +From: Sean 'Shaleh' Perry - 2001-01-09 04:02 + +On 08-Jan-2001 Jorge Arellano Cid wrote: +> +> Hi, +> +> Unfortunately jcid*nettaxi.com seems to be down since the +> first day of 2001; I can send but not receive any email there, if +> anyone has sent me some emails this year, please resend them to +> my jcid*ematic.com address. +> +> I'll appreciate it very much because one of the things I +> really dislike is to loose email, and appear as I'm the one that +> doesn't answer them. +> + +I can hear the list and you just fine. + + + +[Dillo-dev]jcid's nettaxi email account + +From: Jorge Arellano Cid - 2001-01-09 00:57 + +Hi, + +Unfortunately jcid*nettaxi.com seems to be down since the +first day of 2001; I can send but not receive any email there, if +anyone has sent me some emails this year, please resend them to +my jcid*ematic.com address. + +I'll appreciate it very much because one of the things I +really dislike is to loose email, and appear as I'm the one that +doesn't answer them. + + +Thank you very much. +Jorge.- + + + +[Dillo-dev]First post? + +From: Jorge Arellano Cid - 2001-01-08 18:10 + +Hi there! + + +I hope you had enjoyed your Christmas and New year festivities. +For those of us that remeain tuned (not on vacation yet), I would +like to remind that dillo-0.3.1 was released and that its ready +for download at the regular place. + +Well, it seems that this 2001 year has troubled computers a bit +more than the so publicited Y2k. Some servers are working partly +and frankly I don't know if our mailing list is up. BTW: I +haven't received mail from developers since Dec 2000... +Particularly, I want to contact Sebastian (I wrote hime twice +before this mailing-list-try). + +Sourceforge still has problems with hit counters (page and +downloads), but everything else seems fine. + + +Cheers +Jorge.- + + diff --git a/old/oldmail/200102.txt b/old/oldmail/200102.txt new file mode 100644 index 0000000..92a7bf8 --- /dev/null +++ b/old/oldmail/200102.txt @@ -0,0 +1,1380 @@ +Re: [Dillo-dev]Bug #1015 + +From: Sebastian Geerken - 2001-02-27 21:42 + +Hi, + +Solving this bug "quick and dirty" (not suitable for arbitrary nested +widgets, only for this special case) works. I'm now developing a +common solution. + +On Tue, Feb 27, 2001 at 05:27:22PM -0300, Jorge Arellano Cid wrote: +> +> Sebastian, +> +> > I've found the reason and I'm thinking about how to solve it best. +> > +> > A few details: When a widget within the page changes its size, this +> > will (in an idle function) result in a call of +> > a_Dw_widget_size_request for the page widget, and then +> > a_Dw_widget_size_allocate, with the requisition becoming a part of +> > the allocation. The latter checks whether the allocation has changed, +> > and this is not always the case in the test page, since a few images +> > cause the page to have its final size. +> > +> > So, the condition, when a_Dw_widget_size_allocate can omit sending +> > the "size_allocate" signal, can be wrong in some cases. + +I forgot: emitting the "size_allocate" signal will call +Dw_page_size_allocate, which then allocates the children. Without +this, they have zero sizes. This was exactly the case. + +> It looks like the problem we have, but why it works sometimes? +> Because the idle function can be triggered either before or after +> the page allocation gets its final size? If this is true, then +> we're very close to 0.4.0 release! + +(Actually the idle function may be triggered several times, depending +on whether data is available from the Cache module or not.) The bug +does not occur, when all image sizes get known at quite the same +time. In this case, the idle function is called the last time, after +the page widget knows the correct sizes of the image widgets. + +Sebastian + + + +Re: [Dillo-dev]Bug #1015 + +From: Jorge Arellano Cid - 2001-02-27 20:47 + +Sebastian, + +> I've found the reason and I'm thinking about how to solve it best. +> +> A few details: When a widget within the page changes its size, this +> will (in an idle function) result in a call of +> a_Dw_widget_size_request for the page widget, and then +> a_Dw_widget_size_allocate, with the requisition becoming a part of +> the allocation. The latter checks whether the allocation has changed, +> and this is not always the case in the test page, since a few images +> cause the page to have its final size. +> +> So, the condition, when a_Dw_widget_size_allocate can omit sending +> the "size_allocate" signal, can be wrong in some cases. + +It looks like the problem we have, but why it works sometimes? +Because the idle function can be triggered either before or after +the page allocation gets its final size? If this is true, then +we're very close to 0.4.0 release! + +> PS: Jorge, what is the matter with your ematic account? I got a +> failure notice mail, saying: "550 Command RCPT User +> not OK". + +Ematic isn't very stable, I have some problems from time to +time; if this persists, let me know and I'll switch back to +nettaxi. + + +Jorge.- + + + +Re: [Dillo-dev]Bug #1015 + +From: Sebastian Geerken - 2001-02-27 16:32 + +Hi! + +On Fri, Feb 23, 2001 at 06:00:28PM +0100, Sebastian Geerken wrote: +> [...] +> I'll continue to investigate it. + +I've found the reason and I'm thinking about how to solve it best. + +A few details: When a widget within the page changes its size, this +will (in an idle function) result in a call of +a_Dw_widget_size_request for the page widget, and then +a_Dw_widget_size_allocate, with the requisition becoming a part of +the allocation. The latter checks whether the allocation has changed, +and this is not always the case in the test page, since a few images +cause the page to have its final size. + +So, the condition, when a_Dw_widget_size_allocate can omit sending +the "size_allocate" signal, can be wrong in some cases. + +Sebastian + +PS: Jorge, what is the matter with your ematic account? I got a +failure notice mail, saying: "550 Command RCPT User + not OK". + + + +Re: [Dillo-dev]Handling of style and script elements + +From: Jorge Arellano Cid - 2001-02-27 12:27 + +On Tue, 27 Feb 2001, Sam Dennis wrote: + +> > + DILLO_HTML_PARSE_MODE_STYLE, +> +> Do we really need two functionally identical parsing modes? Why not just use +> DILLO_HTML_PARSE_MODE_SCRIPT? + +I agree, and with a short comment that states what _SCRIPT +parsing mode is being used to. + +Jorge.- + + + +Re: [Dillo-dev]Handling of style and script elements + +From: Sebastian Geerken - 2001-02-27 11:06 + +On Tue, Feb 27, 2001 at 12:24:21AM +0000, Sam Dennis wrote: +> On Sun, Feb 25, 2001 at 08:55:50PM +0000, Mark McLoughlin wrote: +> > diff -ur ./dillo-old/src/html.c ./dillo/src/html.c +> > ... +> > + /* spec suggests STYLE is only valid inside HEAD */ +> > + if (html->InTag != DILLO_HTML_IN_HEAD) +> > + return; +> +> The style tag may only be valid inside head, but that doesn't mean that we +> shouldn't catch it elsewhere, especially as we're just ignoring the content +> for now. +> +> > + DILLO_HTML_PARSE_MODE_STYLE, +> +> Do we really need two functionally identical parsing modes? Why not just use +> DILLO_HTML_PARSE_MODE_SCRIPT? + +And call it DILLO_HTML_PARSE_MODE_IGNORE? The CSS parser will +probably read the text from the stash, and in future, we will anyway +need to ignore parts of the doc (e.g.