- Dillo-dev - lists.mailman3.com

[PATCHES] hand_cursor and image_popup, some remarks

by Frank de Lange

[ Jorge, your mailserver is not healthy... I tried to send this 3 times without success, so it goes to the list instead... ] On Mon, 8 Sep 2003 11:13:32 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.org> wrote: > You're right. In that case it causes more troubles than help. > Please send me the patch to commit it to CVS. It is part of the tab/frame patch... It uses the document abstraction. In non-patched Dillo, it would be something like: if(bw->nav_stack_ptr != -1) gtk_widget_grab_focus(GTK_BIN(bw->docwin)->child); else gtk_widget_grab_focus(bw->location); Question is, how much sense does this make in a single-document window? When the window is created, the navigation stack is empty, so focus will always be on the location bar... By the way, there are some problems with 'hidden focus' in Dw. These problems only become directly noticeable in the tab/frame patched version, but they are present in CVS Dillo as well. To see the problem: 1. start dillo on a longish directory listing or a long document (so that the vertical scroll bar appears) 2. use up and down arrow keys to scroll the document. This works in unpatched Dillo. In the (current) patched version, it only works AFTER pressing the UP key once... 3. press SHIFT-TAB twice. Focus is now set on... something. Something invisible. There is no visible focus cue 4. press DOWN key. Nothing happens, no matter how often you press it... Same for TAB, ENTER, RIGHT, ... 5. press UP or SHIFT-TAB or LEFT key. Focus is now on the document, and scrolling keys work as they should. The problem does not show (in patched or unpatched Dillo) when in fullscreen mode. I've searched for the cause of this problem, but have not yet found it. > Clashing with other apps. is almost unavoidable (unless we > clone), but we have chosen to rely over an underlying cognitive > model for our UI. It has been very succesful, and praised! > > Now, as a matter of serendipity :), the bouncing keyboard may > have shown us both a better way. If we make Ctrl-L focus the > location bar (as Ctrl-U does now) and a second Ctrl-L to clear > it, that may be a good choice. Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not in GTK2 though), so I think it is best to use it for that purpose in Dillo as well. For GTK2, following the toolkit default bindings is the logical thing to do. Even better is to allow users to decide for themselves which bindings they want. GTK2 does not allow this by default, but it can be re-enabled. No matter how well thought out a model is, the user should *always* be able to override the designer's defaults. Even if that user messes up a perfectly thought out cognitive model. That is also why I make just about everything user-selectable using preferences with sane default values. So, one of my next goals will probably be to implement user-selectable accelerators in Dillo... Based on GTK's default mechanisms for doing such a thing. > Of course, a more orthogonal way to do it, is the same > functionality, but inside the location popup. But please > experiment with the above suggested idea, and tell me your > findings. Generally I find that popup menu's are more a hinder than a help. This is more of a problem with window managers which do not correctly manage them than with the basic concept of popups, but as the state of the art currently stands I try to avoid them as much as possible. I will therefore try to implement the functionality of Dillo's transient popups (find and open url) in the main window, the former probably in the status bar and the latter in the location bar. And, of course, make a preference to allow the user to choose which version to use - popup or main window. As for using CTRL-L for clearing the location bar, I do not think this is a good idea. But, it is not for me to say it is a bad idea either. > PS: If you send me the requested patches, chances of fast commit > are very high Attached two patches, one for hand_cursor, one for right_click on image. Some remarks: The 'image save as' function in the image popup works, but is dependent on the dpi for the actual save function. That dpi (or, rather, wget) does not know how to handle some link types (eg. file: links), so it will fail on those. The hand_cursor patch works fine, but input_images do NOT work as stated in my previous message. Reverse the patch to dw_button.c to get them back to live... Maybe the image popup should be a submenu on other popups? See the frame/frameset popups (in the tab/frame patch) for an example of what I mean. That way, the image can also be accessed in links (and, maybe, in input images, even those currently do not react to RMB-clicks for obvious reason...) Please be aware of the fact that I will have to keep on adding these patches to the tab/frame patch while the document abstraction has not been committed to CVS... So I will have to patch my own patches, not something I want to keep on doing too long... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 9, 2003

Re: [Dillo-dev] Two small things that need implementation...

by Thorben Thuermer

On Tue, 2 Sep 2003 10:08:33 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > Hi, > > These things have waited for a long time unimplemented. Both > don't require much code, but some knowledge: > > 1.- A right-click popup for images > (we have all the code and functions of it, what we need is > to hook an empty popup to right-click over images). That's imho a VERY essential feature... and i have it in my dillo, for months now... i'm using this patch: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-January/000038.html it has some rough edges, but it works and it's been around for quite some time now (long enough so somebody might have fixed the bugs?)... > Cheers > Jorge.- Greetings, Thorben

Sept. 9, 2003

Re: [Dillo-dev] Feature request - Open tab in background

by Frédéric Bothamy

* Colin Michael Yates <colin.yates(a)orange.net> [2003-09-08 11:49] : > Hi, > > Is it possible to open a tab in the background, instead of it always > getting focus? > > I generally go to a forum (for example), and open the messages that I > want to read in a seperate tab, when I have selected all the messages I > want to read, I then go through them one by one. > > Is this feature already implemented, or does anybody with more C coding > skill then me want to implement it :) It is already implemented if you use Franke de Lange's "tab+frame" patch (I don't know about the current CVS status). Just set the option tab_load_in_background to YES in the dillorc file (either /etc/dillorc or ~/.dillo/dillorc) (default value is NO). Fred

Sept. 8, 2003

Feature request - Open tab in background

by Colin Michael Yates

Hi, Is it possible to open a tab in the background, instead of it always getting focus? I generally go to a forum (for example), and open the messages that I want to read in a seperate tab, when I have selected all the messages I want to read, I then go through them one by one. Is this feature already implemented, or does anybody with more C coding skill then me want to implement it :) Cheers, Colin

Sept. 8, 2003

FW: [Dillo-dev] How do your clear the dillo cache

by Ronald W. Henderson

Folks: Let me be more accurate with my problem: The graphic images (which are *.png files) are the ones which are cached. If I hit the reload botton the html code updates ok but the graphics don't. I need to start and stop Dillo for the graphic images to be updated. Folks: How do you clear the Dillo cache? I am using dillo (0.7.3) to view an updated local html file: "file:xxx.html". I have to stop and restart dillo to see the updates. The "Reload" Button or open file menu option just keeps loading the cached pages... Thanks.. _______________________________________________ Dillo-dev mailing list Dillo-dev(a)lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 7, 2003

How do your clear the dillo cache

by Ronald W. Henderson

Folks: How do you clear the Dillo cache? I am using dillo (0.7.3) to view an updated local html file: "file:xxx.html". I have to stop and restart dillo to see the updates. The "Reload" Button or open file menu option just keeps loading the cached pages... Thanks..

Sept. 7, 2003

Check for unterminated quoted strings

by Andreas Kemnade

I found this tag on pages at www.reichelt.de: <A HREF="Info.html?P1mqhKwQAQsAAHVmTEY+Suche+0+50+LM%20324%20D%20SMD+lm324" onmouseover="return overlib('<TABLE><TR><TD><font face=\'Verdana, Arial, Helvetica, sans-serif\' size=1 color=\'#FFFFFF\'></font></TD></TR></TABLE>',CAPTION,'LM 324 D SMD');" onMouseout="return nd();"> It looks like correct html to me or am I wrong? But dillo does not render it correctly. It is rendered like this: <A HREF=... onmouseover="...TABLE"><TR><TD>... So the check for unterminated quoted strings confuses the table handling. With a small change to html.c, it will be rendered correctly: /* Skip over quoted string */ buf_index++; buf_index += strcspn(buf + buf_index, - (ch == '"') ? "\">" : "'>"); + (ch == '"') ? "\"" : "'"); if ( buf[buf_index] == '>' ) { /* Unterminated string value? Let's look ahead and test: * (<: unterminated, closing-quote: terminated) */ I don't know why that check is there. Does HTML allow quoted strings to be not terminated? I guess there is a better solution than mine. Greetings Andreas Kemnade

Sept. 6, 2003

Re: [Dillo-dev] Re: [Patch] Search feature and more

by Jorge Arellano Cid

Hi Johan! It took a long time to analyze the three patches, but finally here we are: [I'm not quoting the previous email bacause it got too big and can be easily found at the web archives] The patches were: 1.- Made main document window grab focus on startup and after open url. Commited! In the meanwhile, Owen taylor answered my post to GTK-list and it become clear that the "Nirvana"-widget issue is solved in GTK2. Thanks a lot for your comments on this. You may find interesting to read the answer: http://mail.gnome.org/archives/gtk-list/2003-June/msg00307.html 2.- Accelerator keys. Huh! These are to be picked very carefully! It took me a lot of work to figure simple mnemonic shortcuts that integrate well with the UI model. The chosen ones are: Shortcut Mnemonic ------------------------------------------------------------ Ctrl-U "Ctrl-URL" (to edit the URL) Ctrl-H "Ctrl-Hide" (Hide/show controls) Ctrl-S "Ctrl-Search" (search the web) Ctrl-R "Ctrl-Reload" (reload current page) ------------------------------------------------------------ (integrating with the existent) Ctrl-L "Ctrl-Location" (enters a new URL) Ctrl-F "Ctrl-Find" (find text) Ctrl-Q "ctrl-Quit" (quit window) (Note: Ctrl-S is not implemented yet) These should provide good defaults as Havoc suggests. Please give them a test drive to get the feel. Ah, while thinking of it, I thought it'd be good to add the ESC key as a way to switch from the location box into the main window, it can be easily done with the key handler you wrote. 3.- Search feature Uncommited yet, the functionality is perfect. Just some minor details in the UI: A small icon to the right of the location box (hideable as the othe icons), with Ctrl-S as shortcut, that pops up a dialog (just as find text and open url). The icon's tooltip can be "Search the Internet", "Search the Web", or something better :-) The final touches: * While working on the location bar shortcuts, I thought it'd be good to add the ESC key as a way to switch from the location box into the main window, it can be easily done with the key handler you wrote. * It'd be also good to add middle-click over the clear-url button, as a way to "paste-push" an URLs. Instead of the the current three step sequence: - Press clear-url - Paste URL - Press enter I carefully considered your previous email and this model should take good care of the several points we talked about. Half of the work is on CVS now, and the above mentioned details are pending. Please send me a new patch with the modifications to fast-track-commit-it-in! Best Jorge.-

Sept. 5, 2003

Re: [Dillo-dev] Something to think about: free vs. proprietary OSes

by Andreas Schweitzer

Hi, On Thu, Sep 04, 2003 at 01:59:51PM +0000, Phil Pennock wrote: > On 2003-09-04 at 00:11 -0700, Kelson Vibber wrote: > > Where do we draw the line... and why? Compatibility? Ideology? And to throw in even more flamebait (which I will not defend :-) ... ) The BSD's are not really free software in the meaning of FSF's definition ;-) ... To me, it doesn't matter, though. > Suggestion: the point where conditional code compilation is being > scattered throughout the code. On the other hand, it is truely beneficial for producing clean code (i.e. not lots of ifdefs) when trying to compile on largely different platforms. I speak from experience when I say that trying to compile with a different compiler (or on a different platform) usually reveals bugs. So far, dillo is mainly compiled with gcc - I'm not sure about the various solaris efforts, though. I personally once tried IBM's xlc compiler on AIX. It mostly worked and resulted in a few minor code cleanups, that went into dillo. Hmmm, I really should try Intel's IFC or tendra at some point .... Anyways, that alone would make a native Windows port at least interesting. Not that I have any experience with Micorsofts C-compiler, nor that I know about Windows Posix compliance (didn't some Windows version receive some sort of Unix specification ?). Still, I'm sure things will show up that may be real bugs. And these are just the purely technical and objective issues that came up when reading the recent mails on this list :-) > Jorge: I've been at a conference and now am on a different desktop, so > am not easily able to test the alternate fix for FreeBSD and the IO > errors -- since Andreas reports that things work fine for him now, I'll > take it on faith that the problem has been resolved -- thanks for the > prompt response! It doesn't lock up any more. Sometimes, I'm not sure if there are still issues or not. It simply may be the local network like DNS servers etc. As I said, I'll report problems once I'll find them :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 5, 2003

Re: [Dillo-dev] Something to think about: free vs. proprietary OSes

by Andreas Kemnade

On Thu, 4 Sep 2003 13:59:51 +0000 Phil Pennock <phil.pennock(a)globnix.org> wrote: > (I got forced onto a new box and made a policy decision to go GTK2 only; > I had a brief look at porting to GTK2 and got more stuff compiling, but > part way through realised that I'd messed up badly so dumped that. I > won't have time to look at this again for a while -- sorry) > -- familar linux 0.7 has a gtk2 dillo. gtk1.2 is not installed by default. So there should be patches for a gtk2 dillo somewhere. Perhaps that can be used as a starting point. Greetings Andreas Kemnade

Sept. 5, 2003

Re: [Dillo-dev] could not find font

by Jorge Arellano Cid

Hi, > > Hi, I am using dillo for a project here at the univ. In the course of it I > have had to make some modifications to the dillo source so as to be able > to talk with some `tuple space` server. They don't affect the working of > dillo and are abstracted out. Also I need to get the modified dillo on my > ipaq H3670 for use in the project demo. I did the source changes and > everything seems just great. I compiled it for arm using handhelds.org > public clusters and also managed to get it onto my IPAQ. So far so good. > > However the dillo executable doesnt run and bails out saying: > ---- > ** WARNING **: Can't load any ISO8859-1 font!?! :( > ** ERROR **: Could not find any font. aborting... Aborted > ---- This means all the attempts in Dw_style_font_realize() failed. > The dw_style.c seems to look for a font and I would think it fails if it > doesnt find any. That's it. > But what I dont understand is the vanilla gpe > distribution given by the familiar folks also includes dillo and that > works fine on the SAME ipaq. So somehow that dillo executable knows how to > find the fonts? No. It may be that they don't try with the same fontnames! Make sure both provide the exactly the same Dw_style_font_realize() font. If it's the same, check you're using the same dillorc for both. If the problem still persists, using both on the same machine under the same username, using the same dillorc, I'm puzzled! > I am guessing I need to pass a font dir or something > related to x/xfs here? It also works great if I compile it on a desktop > linux box. I am wondering why it cannot find the fonts on the ipaq only. > > Does anyone have any suggestions on how to get this working? Thanks, As above. Cheers Jorge.-

Sept. 4, 2003

Re: [Dillo-dev] Something to think about: free vs. proprietary OSes

by Phil Pennock

On 2003-09-04 at 00:11 -0700, Kelson Vibber wrote: > Where do we draw the line... and why? Compatibility? Ideology? Suggestion: the point where conditional code compilation is being scattered throughout the code. That way lies a maintenance nightmare. The OpenSSH people have to do this, because every OS is a bit different in how the login process is managed, and even there the main development is done in a "clean" branch, for OpenSSH, and the Portable stuff is maintained separately. For a more historical example, look at wu-ftpd. If differences can be cleanly abstracted, so that people don't need to worry about the differences, then it's probably fine. But if someone's devoting their own personal time to a project, finding one OS which forces #ifdefs everywhere, in every file, just to compile suggests that it's not clean and not sufficiently in line. A grep for "ifdef" in the Dillo .c files shows remarkably little in that regard (most of the ones I see are the frames+tab patch's careful segregation. The most common ifdef is for VERBOSE and after that EXTENDED_COLOR, and those tend to be confined to small spaces. For an example of abstraction of OS differences done right, I like Exim (the Mail Transport Agent). Jorge: I've been at a conference and now am on a different desktop, so am not easily able to test the alternate fix for FreeBSD and the IO errors -- since Andreas reports that things work fine for him now, I'll take it on faith that the problem has been resolved -- thanks for the prompt response! (I got forced onto a new box and made a policy decision to go GTK2 only; I had a brief look at porting to GTK2 and got more stuff compiling, but part way through realised that I'd messed up badly so dumped that. I won't have time to look at this again for a while -- sorry) -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Sept. 4, 2003

Something to think about: free vs. proprietary OSes

by Kelson Vibber

<flamebait> So if Dillo is about 100% free software, including the OS it runs on, does that mean we should reject any patches that help Dillo run on Solaris, IRIX, AIX, HP-UX, Mac OS X and so on? If something breaks compatibility with Cygwin, should we let it slide because Cygwin only runs on Windows? What's next, dropping support for SuSE because it's less free than Debian? Red Hat because they call it "Linux" instead of "GNU/Linux?" </flamebait> Where do we draw the line... and why? Compatibility? Ideology? If someone came up with a way to get a working prototype on Mac OS classic, without any effort on your part, would you reject their contribution because the OS is proprietary? If yes, what makes Solaris different? If no, what makes Windows different? A consensus on this issue would be useful, especially the next time someone expresses interest in using Dillo on a nonconventional platform. -- Kelson Vibber www.hyperborea.org

Sept. 4, 2003

could not find font

by Vikram

Hi, I am using dillo for a project here at the univ. In the course of it I have had to make some modifications to the dillo source so as to be able to talk with some `tuple space` server. They don't affect the working of dillo and are abstracted out. Also I need to get the modified dillo on my ipaq H3670 for use in the project demo. I did the source changes and everything seems just great. I compiled it for arm using handhelds.org public clusters and also managed to get it onto my IPAQ. So far so good. However the dillo executable doesnt run and bails out saying: ---- ** WARNING **: Can't load any ISO8859-1 font!?! :( ** ERROR **: Could not find any font. aborting... Aborted ---- The dw_style.c seems to look for a font and I would think it fails if it doesnt find any. But what I dont understand is the vanilla gpe distribution given by the familiar folks also includes dillo and that works fine on the SAME ipaq. So somehow that dillo executable knows how to find the fonts? I am guessing I need to pass a font dir or something related to x/xfs here? It also works great if I compile it on a desktop linux box. I am wondering why it cannot find the fonts on the ipaq only. Does anyone have any suggestions on how to get this working? Thanks, Vikram

Sept. 4, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Eric GAUDET

-- En reponse de "Re: [Dillo-dev] Dillo on Windows fork" de Robin Rowe, le 04-Sep-2003 : > Jorge, > > That you have so many derogatory names for Windows doesn't make a Windows > developer feel welcome. > Many, many, many people came to this list, asking question, proposing patches, etc. All of them were welcome and answered nicely. But you're in a Free Software community: if you can't stand the heat, if you can't keep a low profile, scoot. Why do you feel so personal about windows anyway? > Either a native Windows port is welcome (that means no cygwin in case you > don't understand), you want any patches I create for building Dillo as a > Microsoft Visual C++ project, want to work together, and are happy to > answer what technical points you can regardless of operating system I > use -- or you don't. > I already explained why, personally, I did not want a windows port integrated in Dillo. A fork is ok, though. There's probably way too much changes between Posix and Windows for the two projects to live together anyway. > I am willing to admit that I have no idea what you are talking about in > general. Your previous email, the one from last week that did not attempt > to answer my technical questions about Dillo as it is implemented now, > told me that "if you want to make dillo run on M$ Windoze natively, > you're on your own", and pointed me for the reason to an article whose Dillo's web site has plenty of references about why Jorge (and Dillo's developers agree, I think) think Free Software is what he wnats to develop for. Not any open source project: Free Software. > only reference to Windows is a rant against "Micro$oft (windoze)", > could have led me to the wrong conclusion. All your talk today about > having no Windows users currently, cygwin, posix, articles, attacks, > FUD, false assertions, lies, the dark side (as you call running Dillo > on Windows) and so forth only confuses things further. > Now you're the one being offensive here. > What do you really want me to do? > If you have technical question, ask them, you'll be answered. Or not. Anyway: TAKE THIS DISCUSSION OFF THE LIST! This is a development list, not a fighting list between you and Jorge. This list has a long history of moderation and politeness, and I like it like that. It was never about Jorge, anyway. Didn't you get it? Jorge just happens to be the maintainer and lead developer of Dillo's current main tree. And he's pretty good at it too. But if he's not good enough and somebody feels like forking, developers will go with the most active and appealing project. You don't need Jorge or any of us to tell you what to do. But since you need clarification, here goes: - if you have any technical question, ask them in the list. Politely. - I don't think Jorge will ever consider merging your patches, or any patch about a Windows port. - nobody can or will ever want to prevent you to fork or use Dillo's code in any way you want, provided it's compatible with the GPL. Please, please, nobody answers this message (or this thread in the list). You can answer to me personally if you want to, but I think everything's clear now. Good luck with your project. Best, EG

Sept. 4, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Robin Rowe

Jorge, That you have so many derogatory names for Windows doesn't make a Windows developer feel welcome. You went to a lot of trouble to mince point by point through my "attacks, FUD, and all the false assertions", but it was unnecessary. If it is what you feel, all you need say is that you welcome a native Windows port, that it was just a big misunderstanding. Either a native Windows port is welcome (that means no cygwin in case you don't understand), you want any patches I create for building Dillo as a Microsoft Visual C++ project, want to work together, and are happy to answer what technical points you can regardless of operating system I use -- or you don't. I am willing to admit that I have no idea what you are talking about in general. Your previous email, the one from last week that did not attempt to answer my technical questions about Dillo as it is implemented now, told me that "if you want to make dillo run on M$ Windoze natively, you're on your own", and pointed me for the reason to an article whose only reference to Windows is a rant against "Micro$oft (windoze)", could have led me to the wrong conclusion. All your talk today about having no Windows users currently, cygwin, posix, articles, attacks, FUD, false assertions, lies, the dark side (as you call running Dillo on Windows) and so forth only confuses things further. What do you really want me to do? Cheers, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Sept. 4, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Jorge Arellano Cid

Hi there, Unfortunately, I find myself compelled to answer to Mr. Robin Rowe's attacks, FUD, and all the false assertions he did about myself. Although I knew very few people would take the time to read the interview and then compare it to what Mr. Rowe says I said, I expected, from the long time you know me on this list, not to beleive his attacks without a hesitation. I'll make quotes and comment them. Please make your own comparisons and decide. Of course, you can browse the mailing list archives for the full threads: http://news.gmane.org/thread.php?group=gmane.comp.web.dillo.devel (search for September 2003) -- I'm quoting my missing emails, in full, here. Once I read that the only way to stop FUD was to rebate it point by point, so here I go: > Now, if you want to make dillo run on M$ Windoze natively, > you're on your own. Some of the reasons may be found in the > interview page: > > http://www.dillo.org/interview.html > > Thanks for the link. Very interesting. You sound quite hostile to Windows > users as a matter of personal politics. Please go to the interview and read it. If not at least search for these keywords: "windo" and "user". > May I ask, what does a policy of denying Dillo technical support to Windows > users accomplish? Unless using CYGWIN we have no Windows users because there's not a working native port yet. How can I be blamed for not supporting non-existent users? > Do you intend to prevent people from using software they > have already paid for anyway? _Ridiculous_. How can I prevent all (or some) of the windows users using their OS of choice. Mr. Rowe puts me as if I was trying to actively deny these people the right to use their SW. How? Turning off theiy machines from my house? Has anyone ever read such an statement from me in this mailing list? I read it again and again and can't understand why I'm bashed this way. > Should I throw away my copy of Windows 2000 to > accommodate your political views? Please, please, read the interview and search for such an statement. Incredible, Mr. Rowe keeps inventing implicit assertions, and then charging them on me. I've never said that. You can chose whatever OS you want. I'm only the project leader of a Free-SW project that aims for POSIX compliance. I even suggested him to try the recipe Kelson prepared about running dillo on Windows with CIGWIN. (http://www.hyperborea.org/software/dillo/cygwin.html) > To what point? I don't know, it was Mr. Rowe who invented this false accusation and blamed me for it. > You can't think it could > hurt Microsoft. And he suggests what I think too! Amazing. > You must know they aren't going to give me a refund. Please search for the keyword "refund" in the interview. You will not find it. It is just another invention that I'm accused for by Mr. Rowe. > If you change your mind and decide to answer my questions about what a few > troublesome pieces of Dillo code are intended to do that would be nice. Gentle words after the bashing. (this can confuse the careless reader, and make him think he's going through valid statements.) > But, if you prefer not to it is no big deal. Interesting. Then why did he take the time to prepare a set of false statements to attack me? > I've ported much more difficult > programs without help. To some extent, this is a compliment (I believe in Raph Levien's words that "SW design is a constant struggle against complexity"), but frankly I think his intention wasn't that. ...and as if this wasn't material enough, here are some other quotes from the next emails he sent: > In response to my request for technical information about Dillo to make it > easier for me to debug the Windows port, Jorge sent me an email off-list > last week in which he told me, "you're on your own" and directed me to > his interview at http://www.dillo.org/interview.html for the reason why. > What Jorge says there is he is opposed to supporting Windows users as a > matter of personal politics. Another lie! He says: "Jorge says there is he is opposed to supporting Windows users as a matter of personal politics". Here's my email: <q> On Thu, 28 Aug 2003, Robin Rowe wrote: > Jorge, > > I have Dillo built now as a native Windows VC++ 6 project and am debugging > it. Seems to be my unstable 1.14 version of GTK for Windows that is causing > Dillo to hang on load. By the way, I'm the new GTK1 for Windows maintainer. > Tor and GIMP for Windows are moving to GTK2, but CinePaint is staying with > GTK1. > > Can we talk about Dillo design portability a bit? Dillo is designed to run on POSIX compatible systems. If CYGWIN provides that, let it be (as stated in Kelson's doc). Now, if you want to make dillo run on M$ Windoze natively, you're on your own. Some of the reasons may be found in the interview page: http://www.dillo.org/interview.html (search for "windows", is quite a large text). Cheers Jorge.- </q> ------------------------------------- and here's my previous answer to him: ------------------------------------- <q> On Tue, 26 Aug 2003, Robin Rowe wrote: > Hi. I'm the project leader for CinePaint, an open source paint program used > mainly by the motion picture industry. Our code was branched from GIMP in > 1998. Hi! Yes, I knew about your project by the time we were applying to LinuxFund... > > How would the Dillo project feel about Dillo being embedded in another > application as a help browser? Very good. In fact it has been done in the past with the Sylpheed-claws email client: it embeds dillo for secure HTML mail viewing. In fact we're working in a remote control plugin for dillo to allow better support for this kind of functionality. Currently applications can launch Dillo and let the user navigate the help docs without problems. Now, if the app. wants to provide context sensitive help, it needs to end dillo and launch another instance to make it display the required page (quite fast, but not optimal), and here's where we're improving it. > We're looking for a new help system browser and considering Dillo. We are > impressed how compact your implementation is. We only need a limited set of > HTML features: links, images, tables, bullet lists, number lists, headings, > ordinary text, bold, and italic. In these features we need the browser to be > absolutely stable. Any issues there? None! You'll hardly find a browser that's more stable. And for any issue that may arise, you can email us back for support. > > We support all platforms, including Windows. One of the first things I would > intend to do is port Dillo to Windows. I saw in your archives that you had > made some effort in that direction, but it seemed to peter out. What are the > problems? If you need dillo to run on the dark side, take a look at: http://www.hyperborea.org/software/dillo/cygwin.html Cheers Jorge.- </q> ----------- Now, please excuse me if I don't want to answer any other email from Mr. Robin Rowe. I refuse to answer to Mr. Rowe because he has not the minimal manners to communicate politely and objectively (at least with me), and he attacks me upon false statements. ----------- Now, onto the technical reasons why I decided to aim dillo for POSIX and not for Windows (the use of advanced features of POSIX is a fact documented in a paper I wrote the year 2000). From Dillo project objectives perspective: The project objectives are: * The democratization of Internet information access. * Security and personal privacy. * High software efficiency. 1.- The democratization of Internet information access. Windows requires a modern machine to run (at least supported versions of it), and the pay of a licence fee. People with such a HW/SW configuration already have the means to afford their internet access. Now considering what happened to Netscape when trying to run on Windiws platforms it was quite clear there was no much future on that line. 2.- Security and personal privacy. Definitively a hard conflict with the windows platforms. A lot has been written about this topic, but let me suggest: http://www.hevanet.com/peace/microsoft.htm 3.- High software efficiency. A carefully crafted browser, with every single bit of speed we could think of, running over a bloated monster that makes modern computers feel slow? Now, as a tiny client for help documents, it may be, but Explorer is already loaded so... If someone someday makes dillo run on windows, I'll ask him to warn the users that they don't have the Security and personal privacy the original Dillo strives for (one of the best ways to spy any browser is to do in the internal firewall. You have all the HTTP traffic, the user IDs, etc.) Judge yourselves, I've had enough of it. Sincerely Jorge.-

Sept. 4, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Melvin Hadasht

[Please, let's keep this discussion on the ML] Hi, > > If someone wants to port Dillo to Windows, he > > can look at how Sylpheed-Claws I/O infrastructure was ported to Windows. > > Sylpheed-Claws does not use pthreads, but it forks... > > Windows doesn't fork. That can be emulated with spawn. Threads is a better > approach. I don't know how he did that, but I remember those two parts (IO and forking) were the first things that needed to be ported to Windows. My message wasn't aimed at discussing technical points (I never programmed in Windows), but rather to point to some light-weight gtk 1.2 project that was already successfully ported to Windows, so less experienced developers could take a look on it. > > I think, if someone does not already have the experience of > > porting to Windows.... > > I ported CinePaint to Windows, the largest GTK project ever ported aside > from GIMP. Then disregard my email, it will not help you :). I thought someone was in need of technical help for porting to Windows, so I posted some hints in the case where the poster was not so experienced. > >...looking at Claws versions can be very helpful, as our port > > is done by a very knowledgeable guy. > > Cool, who was that? Just google for Sylpheed-Claws & win32 :) -- Melvin Hadasht

Sept. 4, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Robin Rowe

Kelson, > From where I'm sitting, it looks like you've been *very* welcome here, > with one exception. > > Have people been sending you hate mail off-list? Or had you made up your > mind before you posted your question? Nobody has expressed any hostility. Some are discriminatory, but as someone pointed out the GPL doesn't say you can't discriminate against Windows users. Once the Dillo project leader says Windows is unwanted here there is no reasonable choice for me as the Windows port developer but to go elsewhere. I'm trying to do as the project leader says he wishes. Are you saying Jorge isn't the project leader? That I shouldn't respect his wishes? What I wanted to do was donate the Windows port. I had no idea that would be made difficult. Cheers, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Kelson Vibber

At 02:06 PM 9/3/2003, Robin Rowe wrote: >It seems clear that I must take Dillo for Windows elsewhere, that opinions >are too firmly set for Windows users to feel welcome here soon. OK... I've seen four replies to your question (not counting Jorge's). Three of them basically say, "Yes, let's port to Windows!" One simply states that nothing forces Jorge to support it and offers no opinion on porting one way or the other. Additionally, several people replied to your earlier technical questions to the list, and several people expressed interest in your progress. From where I'm sitting, it looks like you've been *very* welcome here, with one exception. Have people been sending you hate mail off-list? Or had you made up your mind before you posted your question? Kelson Vibber www.hyperborea.org

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Melvin Hadasht

Hi, > That does not necessarily mean the project has to be forked, only that > someone needs to be willing to maintain the Windows code - by which I mean > (at the very least) following the development process and making sure that > changes don't break Windows compatibility. Otherwise we'll end up with the > same situation that killed Classic Mac OS support on Mozilla. AFAIK, the port of Sylpheed-Claws to Windows uses gtk 1.3.x (which is closer to gtk 2.x than to gtk 1.2.x). If someone wants to port Dillo to Windows, he can look at how Sylpheed-Claws I/O infrastructure was ported to Windows. Sylpheed-Claws does not use pthreads, but it forks to access to POP3 mailboxes, as Dillo forks to do DNS lookups, IIRC. We have a CVS branch for the Windows port. I think, if someone does not already have the experience of porting to Windows, looking at Claws versions can be very helpful, as our port is done by a very knowledgeable guy. -- Melvin Hadasht

Sept. 3, 2003

RE: [Dillo-dev] Dillo on Windows fork

by Eric Gaudet

> Kelson, > > > If Jorge does not want to work on a Windows port, that's up > > to him.... > > That does not necessarily mean the project has to be forked.... > ... > It seems clear that I must take Dillo for Windows elsewhere, > that opinions are too firmly set for Windows users to feel > welcome here soon. It isn't a problem to put my version on > SourceForge. Does anyone here want to get involved now or > shall I go it alone? > That's the beauty fo the GPL: even if the developers of Dillo don't want to help with a feature, a port, you can still do it. And if you end-up adding interesting stuff, Dillo can even get it back! ... > Should I choose a new name for the Dillo fork on SourceForge? > It's not required, AFAIK. The only requirement is to release the sources under the GPL with any release you do. Regarding the need for a windows port, I don't quite see who would need such a thing (besides you, obviously). Windows has phoenix, which is lightweight enough when the OS itself need a big machine only to boot. As for running old versions of windows on a small machine, it really is ludicrous. Running an OS that's unsupported, crash-prone and hopelessly outdated like W9x sounds like a bad idea. This kind of machine is a perfect target for a small linux. Good luck anyway. Eric

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Robin Rowe

Kelson, > If Jorge does not want to work on a Windows port, that's up to him.... > That does not necessarily mean the project has to be forked.... No one has asked Jorge to work on the Windows port. My request was for technical information about the *Linux* implementation of Dillo. Jorge won't answer my Linux questions. He chooses not to help even indirectly, because I would use that information to work on Windows. > Maybe it'll take time for the changes to work their way into the main > branch. Who knows? Does it matter? It seems clear that I must take Dillo for Windows elsewhere, that opinions are too firmly set for Windows users to feel welcome here soon. It isn't a problem to put my version on SourceForge. Does anyone here want to get involved now or shall I go it alone? Jorge, what should be done about the Dillo name? CinePaint used to be called Film Gimp, a name inherited from an abandoned branch of GIMP that at one time was expected to be the next GIMP. Confusion with the GIMP project prompted our name change. Film Gimp users would sometimes wander into the GIMP list causing annoyance and confusion. Any Dillo for Windows users who come to this Dillo list expecting to be welcomed and supported will be wasting everyone's time. Should I choose a new name for the Dillo fork on SourceForge? Thanks, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Kelson Vibber

Personally, I think that Windows compatibility could be beneficial for Dillo. If the goal is to make the Internet more widely available on less-expensive (in other words, older) hardware, it seems to me that making Dillo available on the large number of old Win9x systems would help. Recently, my brother picked up a cheap PCMCIA network card, dragged my parents' decade-old laptop off the shelf, and plugged it into their home LAN. This system is old enough that we installed Windows 95 on it when the OS was new. At one point, my brother turned to me and asked if I knew of a good web browser to run on a really old system. I said, "Well, if this were Linux, I'd recommend Dillo, but..." We ended up installing Opera, which still took about a minute to start up, but ran reasonably well afterward. Of course, there is the matter of developer interest. If Jorge does not want to work on a Windows port, that's up to him. This is free software, after all! As I understand it, he has expressed no objection to the existence of a port, but he does not want to be involved in the process. That does not necessarily mean the project has to be forked, only that someone needs to be willing to maintain the Windows code - by which I mean (at the very least) following the development process and making sure that changes don't break Windows compatibility. Otherwise we'll end up with the same situation that killed Classic Mac OS support on Mozilla. Maybe it'll take time for the changes to work their way into the main branch. The code to embed Dillo in Sylpheed, for instance, was a series of patches for a long time before it was added, and the tabs/frames patch (or parts of it) will probably follow the same path. The same thing could happen with the Windows port. Kelson Vibber www.hyperborea.org

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Tom Lisjac

On Wed, 2003-09-03 at 09:34, Colin Michael Yates wrote: > Given that Linux is about choice... Yes, Linux and open source development is very much about choice... and one them is how a developer chooses to spend his or her time. It's hard work to build a project like this, but the reward is doing something that the creator believes is worthwhile. Nobody is being paid... so this doesn't need to conform to anyone else's idea of what "worthwhile" is. The GPL allows the code to be modified by anyone who chooses to... but it doesn't require the author to do work that he doesn't enjoy doing. > Fair enough having a personal agenda, but enforcing it on others (i.e. > being hostile) isn't really on. Hostility and indifference are two very different things. I haven't seen any hostility on this list... yet. Best regards, -Tom

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Colin Michael Yates

Given that Linux is about choice, and the fact that we Linux users moan so much about MS apps not running on Linux, it kind of seems hypocrtical to support *only* Linux! Fair enough having a personal agenda, but enforcing it on others (i.e. being hostile) isn't really on. I am quite dissapointed now. I moved away from Microsoft to get rid of this kind of thing :) On Wed, 2003-09-03 at 08:09, robert w hall wrote: > In article <02d101c371a7$137a5fd0$0200a8c0@tbird>, Robin Rowe > <rower(a)MovieEditor.com> writes > >Colin, > > > >> Any chance of a downloadable exe? > > > >Yes I'd be glad to, but the Windows port is not ready yet for release. I got > >as far as the splash screen. Still more bugs to fix. Encouraging though. > > > >In response to my request for technical information about Dillo to make it > >easier for me to debug the Windows port, Jorge sent me an email off-list > >last week in which he told me, "you're on your own" and directed me to > >his interview at http://www.dillo.org/interview.html for the reason why. > >What Jorge says there is he is opposed to supporting Windows users as a > >matter of personal politics. > > Well, for me, one of the annoying things about M$ is it's policy of > aggressive obsolescence. Support for NT3.51, NT4, win95, win98 has > already gone - but these systems have life left in them and are > appropriate to the smaller machines of their time. > I would have thought supporting a browser to run on these earlier > machines would in no way be helping the Gates empire to 'world > domination', quite the reverse... > > Bob > >

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Robin Rowe

Robert, > Well, for me, one of the annoying things about M$ is it's policy of > aggressive obsolescence. Let's not debate the pros and cons of Microsoft. It isn't that interesting and anyone with an opinion is unlikely to change it. In my world, that is, motion picture animation and special effects, the O.S. situation is very different from elsewhere. If you read my articles in Linux Journal then you are aware that in motion picture production Linux dominates as the most popular O.S. on servers and desktops. Windows isn't even a close second. The largest corporate installations of Linux in the world are DreamWorks, ILM, and Disney. To support all operating systems -- even minor ones like Windows -- is a mark of professionalism where I come from. Cheers, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Sept. 3, 2003

Re: [Dillo-dev] Dillo configure cannot find zlib, jpeglib not libpng

by Sebastian Geerken

On Thu, Aug 14, Scorpio Rising wrote: > I have a configuration problem in Debian stable. > > The configure file cannot find/use the z, jpeg or png libs that are in > /usr/include. > > *** cannot locate***......disabling jpeg/png/libz > > I have tried the command line options and even hardcoding the paths in > configure.in to no avail. > > I have installed the dev-headers for these packages. If you haven't solved the problem otherwise ... Perhaps you have installed the wrong versions. With the following packages, dillo compiles and run fine for me: $ dpkg --list "*zlib*" "*libjpeg*" "*libpng*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ pn libcompress-zl <none> (no description available) pn libzlib-ruby <none> (no description available) un python-zlib <none> (no description available) un zlib <none> (no description available) pn zlib-bin <none> (no description available) pn zlib1 <none> (no description available) pn zlib1-altdev <none> (no description available) un zlib1-dev <none> (no description available) ii zlib1g 1.1.4-1 compression library - runtime ii zlib1g-dev 1.1.4-1 compression library - development pn zlibc <none> (no description available) un libjpeg-dev <none> (no description available) un libjpeg-gif <none> (no description available) pn libjpeg-mmx-de <none> (no description available) pn libjpeg-mmx-pr <none> (no description available) pn libjpeg-progs <none> (no description available) ii libjpeg62 6b-5 The Independent JPEG Group's JPEG runtime li ii libjpeg62-dev 6b-5 Development files for the IJG JPEG library un libjpeg6b <none> (no description available) un libjpegg-dev <none> (no description available) pn libpng-dev <none> (no description available) un libpng1-dev <none> (no description available) ii libpng2 1.0.12-3 PNG library - runtime ii libpng2-dev 1.0.12-3 PNG library - development ii libpng3 1.2.1-1.1 PNG library - runtime un libpng3-dev <none> (no description available) If you still fail with these packages, you should send your config.log to the list. Sebastian

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Windows fork

by robert w hall

In article <02d101c371a7$137a5fd0$0200a8c0@tbird>, Robin Rowe <rower(a)MovieEditor.com> writes >Colin, > >> Any chance of a downloadable exe? > >Yes I'd be glad to, but the Windows port is not ready yet for release. I got >as far as the splash screen. Still more bugs to fix. Encouraging though. > >In response to my request for technical information about Dillo to make it >easier for me to debug the Windows port, Jorge sent me an email off-list >last week in which he told me, "you're on your own" and directed me to >his interview at http://www.dillo.org/interview.html for the reason why. >What Jorge says there is he is opposed to supporting Windows users as a >matter of personal politics. Well, for me, one of the annoying things about M$ is it's policy of aggressive obsolescence. Support for NT3.51, NT4, win95, win98 has already gone - but these systems have life left in them and are appropriate to the smaller machines of their time. I would have thought supporting a browser to run on these earlier machines would in no way be helping the Gates empire to 'world domination', quite the reverse... Bob -- robert w hall

Sept. 3, 2003

Re: [Dillo-dev] Problems compiling tab+frame patch on Mandrake and RH 7

by Kelson Vibber

On Tuesday 02 September 2003 2:05 am, Frank de Lange wrote: > These errors can be caused by mismatched autotools (when the one used to > create the configure script does not match the installed version). You can > try to run the autotools manually to recreate the files with your installed > versions of the autotools: Thanks! I've updated the RPM spec for the patched version to (a) check for automake and autoconf, and (b) run them before calling configure. So far, so good on fully-patched RH 7.2 and Mandrake 9.1. I can't test it on Mandrake 8.2 yet, because both the spare partition and UML filesystem have stopped working. I'll probably just start from a fresh Mdk 8.2 UML fs and reclaim the partition. RPMs for Mandrake 9.1 i586 and PPC will be up shortly. -- Kelson Vibber www.hyperborea.org

Sept. 3, 2003

Re: [Dillo-dev] Dillo on Win2k

by Robin Rowe

Robert, > any chance of a version that works on NT3.51 (on a 64Mb dx4-75 :-) ) Yes, a good chance. Likely to work on all Win9x flavors, too. As with *nix, will require testing on each platform. Cheers, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Sept. 2, 2003

Re: [Dillo-dev] Dillo on Windows fork

by Robin Rowe

Colin, > Any chance of a downloadable exe? Yes I'd be glad to, but the Windows port is not ready yet for release. I got as far as the splash screen. Still more bugs to fix. Encouraging though. In response to my request for technical information about Dillo to make it easier for me to debug the Windows port, Jorge sent me an email off-list last week in which he told me, "you're on your own" and directed me to his interview at http://www.dillo.org/interview.html for the reason why. What Jorge says there is he is opposed to supporting Windows users as a matter of personal politics. On Friday the 29th I sent an email to Jorge asking he reconsider, but he hasn't responded. The text of my message is below. I am not enclosing Jorge's message because I don't know if he intended that to be for the record. It seems that contributing to Dillo on Windows is unwelcome and requires forking it. I didn't come to the project with the idea that I would take it over and am a bit perplexed. I'm wondering how others who have been with the project longer may feel. Should Dillo for Windows go elsewhere? If yes, does anyone want to help with it? Thanks, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software ----- Original Message ----- From: "Robin Rowe" <rower(a)MovieEditor.com> To: "Jorge Arellano Cid" <jcid(a)softhome.net> Sent: Friday, August 29, 2003 7:04 PM Subject: Re: [Dillo-dev] Dillo Windows port > Jorge, > > Before discussing Windows issues I thought you may like to know that Tom > Huffman announced today on cinepaint-developers he has completed making > Dillo into a Linux help system plug-in for CinePaint. I anticipate we'll > start including Dillo with CinePaint in October. > > We've been using the GIMP tips widget as our help system. Everyone is > excited about Dillo as a big improvement. We plan to add an editing > capability to Dillo so we can edit our help pages from within Dillo. > > As I said, I'm not using Cygwin. Cygwin, clever as it is, has many > drawbacks. I'm running Dillo natively on Windows. > > It took me about 24 hours to accomplish that, to make some adjustments to > compile Dillo in Microsoft Visual C++. Mostly it involved adding > conditionals to change the names of included header files. Because your > design didn't anticipate that a few of the POSIX calls you use are not > available in Windows, it will take a little more work to replace those, to > complete the job. > > Although Windows is not 100% POSIX compatible, it is much more compatible > than you seem to think. POSIX-based programs can be made to work on Windows > without much trouble if you try. I haven't added any Windows API calls to > the existing Dillo code. > > Thanks for the link. Very interesting. You sound quite hostile to Windows > users as a matter of personal politics. > > May I ask, what does a policy of denying Dillo technical support to Windows > users accomplish? Do you intend to prevent people from using software they > have already paid for anyway? Should I throw away my copy of Windows 2000 to > accommodate your political views? To what point? You can't think it could > hurt Microsoft. You must know they aren't going to give me a refund. > > If you change your mind and decide to answer my questions about what a few > troublesome pieces of Dillo code are intended to do that would be nice. But, > if you prefer not to it is no big deal. I've ported much more difficult > programs without help. > > Cheers, > > Robin > > P.S. For anyone doesn't know, I lead the GTK1 for Windows and the Mac > GTK+OSX port projects in addition to CinePaint. > -------------------------------------------------------------------------- - > Robin.Rowe(a)MovieEditor.com Hollywood, California > www.CinePaint.org Free motion picture and still image editing software

Sept. 2, 2003

Re: [Dillo-dev] CPU hog with large selections

by Jorge Arellano Cid

Sebastian, > Hi, > > On Tue, Sep 02, Jorge Arellano Cid wrote: > > Yesterday I came accross this bug while reading: > > > > http://freshmeat.net/articles/view/889/ (272KB) > > > > If you go to a comment in the middle of the page, start > > selecting text with the mouse, and move it to the leftmost border > > (so it selects all the text up to the start), the CPU will hog > > and dillo will become unresponsive as it was in a dead loop. > > > > For instance, from the bottom line it takes 10 minutes to > > recover on a pentium II 233Mhz. I almost sure this can be > > improved. > > > > Please someone give a hand to fixing it. > > Fixed and comitted. Great! One less problem on the list. > BTW, there is (still) a memory leak in the selection (reproduce this > simply by selecting text several times), but this leak exists also in > the old code, so it is not likely to be caused by the recent changes. I understand. It'd be good if we can coordinate to review the tab + frames patch this week (and next). Do you have some time? Regards Jorge.- PS: I added the missing include for <string.h>

Sept. 2, 2003

Re: [Dillo-dev] CPU hog with large selections

by Sebastian Geerken

Hi, On Tue, Sep 02, Jorge Arellano Cid wrote: > Yesterday I came accross this bug while reading: > > http://freshmeat.net/articles/view/889/ (272KB) > > If you go to a comment in the middle of the page, start > selecting text with the mouse, and move it to the leftmost border > (so it selects all the text up to the start), the CPU will hog > and dillo will become unresponsive as it was in a dead loop. > > For instance, from the bottom line it takes 10 minutes to > recover on a pentium II 233Mhz. I almost sure this can be > improved. > > Please someone give a hand to fixing it. Fixed and comitted. BTW, there is (still) a memory leak in the selection (reproduce this simply by selecting text several times), but this leak exists also in the old code, so it is not likely to be caused by the recent changes. Sebastian

Sept. 2, 2003

Re: [Dillo-dev] Dillo on Win2k

by robert w hall

In article <1062518524.636.16.camel(a)xterm.home>, Colin Michael Yates <colin.yates(a)orange.net> writes >Any chance of a downloadable exe? any chance of a version that works on NT3.51 (on a 64Mb dx4-75 :-) ) -- robert w hall

Sept. 2, 2003

Re: [Dillo-dev] Dillo on Win2k

by Colin Michael Yates

Any chance of a downloadable exe? Colin On Tue, 2003-09-02 at 07:10, Robin Rowe wrote: > FYI, making progress with Dillo on Win2k. > > http://cinepaint.sourceforge.net/pix/windows/dillo.win2k.gif > > Cheers, > > Robin > --------------------------------------------------------------------------- > Robin.Rowe(a)MovieEditor.com Hollywood, California > www.CinePaint.org Free motion picture and still image editing software > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 2, 2003

Re: [Dillo-dev] Two small things that need implementation...

by Jorge Arellano Cid

On Tue, 2 Sep 2003, Frank de Lange wrote: > On Tue, 2 Sep 2003 10:08:33 -0400 (CLT) > Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > > > > Hi, > > > > These things have waited for a long time unimplemented. Both > > don't require much code, but some knowledge: > > > > 1.- A right-click popup for images > > (we have all the code and functions of it, what we need is > > to hook an empty popup to right-click over images). > > > > 2.- Input images work, but there's a detail lacking. The arrow- > > shaped cursor should change to a hand-shaped one (as with > > links). > > > > > > Anyone? > > I've already added these to the tab + frame patch... Excellent Frank! The next thing to do (for me) will be a list of things to be included in 0.8.0, answer Johan H., and start perusing the tab + frames patch. Cheers Jorge.-

Sept. 2, 2003

Sourceforge RSS feed (http://sourceforge.net/export/rss2_projfiles.php?group_id=603)

by Colin Michael Yates

Hi, Just a quick note, the RSS feed from sourceforge is currently listing dillo at 0.6.4. Any chance someone could keep it updated please. The URL is http://sourceforge.net/export/rss2_projfiles.php?group_id=603 Also, just wanted to say *great* tool. Cannot get over how quick it is! If only I knew how to apply the patch to get it to render slashdot ..... Thanks again, Colin

Sept. 2, 2003

Re: [Dillo-dev] Two small things that need implementation...

by Frank de Lange

On Tue, 2 Sep 2003 10:08:33 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > Hi, > > These things have waited for a long time unimplemented. Both > don't require much code, but some knowledge: > > 1.- A right-click popup for images > (we have all the code and functions of it, what we need is > to hook an empty popup to right-click over images). > > 2.- Input images work, but there's a detail lacking. The arrow- > shaped cursor should change to a hand-shaped one (as with > links). > > > Anyone? I've already added these to the tab + frame patch... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 2, 2003

Two small things that need implementation...

by Jorge Arellano Cid

Hi, These things have waited for a long time unimplemented. Both don't require much code, but some knowledge: 1.- A right-click popup for images (we have all the code and functions of it, what we need is to hook an empty popup to right-click over images). 2.- Input images work, but there's a detail lacking. The arrow- shaped cursor should change to a hand-shaped one (as with links). Anyone? Cheers Jorge.-

Sept. 2, 2003

CPU hog with large selections

by Jorge Arellano Cid

Hi there, Yesterday I came accross this bug while reading: http://freshmeat.net/articles/view/889/ (272KB) If you go to a comment in the middle of the page, start selecting text with the mouse, and move it to the leftmost border (so it selects all the text up to the start), the CPU will hog and dillo will become unresponsive as it was in a dead loop. For instance, from the bottom line it takes 10 minutes to recover on a pentium II 233Mhz. I almost sure this can be improved. Please someone give a hand to fixing it. Cheers Jorge.-

Sept. 2, 2003

Re: [Dillo-dev] Problems compiling tab+frame patch on Mandrake and RH 7

by Frank de Lange

On Tue, 2 Sep 2003 10:02:50 +0200 Andreas Schweitzer <Andreas.Schweitzer(a)hs.uni-hamburg.de> wrote: > Hi, > > > On these systems, after un-tarring the Dillo 0.7.3 source and applying the > > appropriate version of the patch, make would always fail at the same point: > > > > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include > > -I/usr/local/include/libpng12 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 > > -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -DXHTML_DTD_FRAMESET > > -DXHTML_DTD_TRANSITIONAL -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return > > -c `test -f 'http.c' || echo './'`http.c > > http.c: In function `Http_query': > > http.c:167: `VERSION' undeclared (first use in this function) > > VERSION is declared in config.h which in turn is produced > by the configure magic. > I highly suspoect that something went wrong during > configure time and config.h got garbeled. > Maybe some time stamps while patching ? And some > of the autotools tried to run although they shouldn't ? These errors can be caused by mismatched autotools (when the one used to create the configure script does not match the installed version). You can try to run the autotools manually to recreate the files with your installed versions of the autotools: % aclocal % autoheader % autoconf % automake -a This should solve the problem. If you do not have these programs, you need to install them... I have seen this on an old RH6.2 box, running the autotools solved the problem. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 2, 2003

table cellspacing and borders

by Ralph Slooten

In my attempts to make a nice design website from pure and propper html, I have discovered that Dillo differs from any other browser when it comes to rendering tables with set widths. Could anyone clarify for me why dillo expands the initially set width of a table when the cellspacing and/or border is increased? What I mean is like this: <table cellpadding="6" cellspacing="10" border="5" width="700" bgcolor="#E3E3E3"> <tr> <td>test</td> <td> test 2</td> </tr> </table> This produces a table which is wider than 700px. If cellspacing="0" and border="0", dillo renders the table fine to it's set width of 700. Is this a bug, or some w3.org specification other browsers like Mozilla / Opera / IE ignore? Using 0.7.3 here if it's any use ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Sept. 2, 2003

Re: [Dillo-dev] Problems compiling tab+frame patch on Mandrake and RH 7

by Andreas Schweitzer

Hi, > On these systems, after un-tarring the Dillo 0.7.3 source and applying the > appropriate version of the patch, make would always fail at the same point: > > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include > -I/usr/local/include/libpng12 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 > -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -DXHTML_DTD_FRAMESET > -DXHTML_DTD_TRANSITIONAL -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return > -c `test -f 'http.c' || echo './'`http.c > http.c: In function `Http_query': > http.c:167: `VERSION' undeclared (first use in this function) VERSION is declared in config.h which in turn is produced by the configure magic. I highly suspoect that something went wrong during configure time and config.h got garbeled. Maybe some time stamps while patching ? And some of the autotools tried to run although they shouldn't ? I had some issues with the autotools after patching but forgot the details - sorry. Touching certain files in a certain order may help to not trigger the autotools. Hope that helps, Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 2, 2003

Dillo on Win2k

by Robin Rowe

FYI, making progress with Dillo on Win2k. http://cinepaint.sourceforge.net/pix/windows/dillo.win2k.gif Cheers, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Sept. 2, 2003

Problems compiling tab+frame patch on Mandrake and RH 7

by Kelson Vibber

I've built RPMs that include version 9 of the tab+frame patch at http://www.hyperborea.org/software/dillo/modified.html (a completely separate page from the mail page with the "vanilla" RPMs). In building these, I ran into problems trying to compile with up-to-date versions of: - Red Hat 7.3 - Red Hat 7.2 - Mandrake 8.2 - Mandrake 9.1 On these systems, after un-tarring the Dillo 0.7.3 source and applying the appropriate version of the patch, make would always fail at the same point: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/include/libpng12 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -DXHTML_DTD_FRAMESET -DXHTML_DTD_TRANSITIONAL -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -c `test -f 'http.c' || echo './'`http.c http.c: In function `Http_query': http.c:167: `VERSION' undeclared (first use in this function) http.c:167: (Each undeclared identifier is reported only once http.c:167: for each function it appears in.) make[3]: *** [http.o] Error 1 make[3]: Leaving directory `/home/kelson/build/dillo-0.7.3/src/IO' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/kelson/build/dillo-0.7.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kelson/build/dillo-0.7.3' make: *** [all] Error 2 The unpatched versions had no problems on any of the above systems. When I checked the patch to see what was changed in http.c, and saw how little there was, I started looking at library versions. At the time I had not tried Red Hat 7.2, so I started up my UML copy. On my first test (just compiling the patched source), it worked. I then checked for and installed updates before trying to build the RPM, and it failed just as the others had. To make a long story short, on Red hat 7.2 I narrowed the problem down to glibc. It worked with glibc 2.2.4-19.3, but not with 2.2.4-32. Unfortunately I can't narrow it down to a version in general. Red Hat 7.3 is on glibc-2.2.5-43, Mandrake 8.2 is on glibc-2.2.4-26.2mdk, and Mandrake 9.1 is on glibc-2.3.1-10mdk. Has anyone else encountered similar problems, and/or come up with a workaround? -- Kelson Vibber www.hyperborea.org

Sept. 2, 2003

Dillo used in Puppy Linux

by Barry Kauler

Hi, Introducing myself, just recently subscribed to this list. I'm developing a super tiny Linux distro called Puppy, that runs totally in a 48M or 64M ramdisk, yet has a full suite of GUI apps. The greatest advantage of having everything always in RAM is the fast startup and response. The 48M version 0.6 is on the web, hosted by ibiblio.org, and uses Hacked Links and Dillo. I'm currently using Dillo as the internal HTML viewer. Note, Puppy has a large amount of docs, in HTML. Also using Sylpheed, not Claws. For the "big" Puppy, running in 64M, I've experimented with Mozilla v0.9.8 and Konqueror-embedded. I've retained Dillo as the internal viewer. Note that the small Puppy uses only apps written in plain C, and only has the Athena (neXtaw) and GTK v1.2 libraries -- which is why I want to encourage you Dillo developers to stick with compatibility with the v1.2 library!!! ...and, I know it's dreaming, but if Dillo can get CSS, SSL, and a few other things, it could be the only browser I need. (Flash, SVG, ....) ... small Puppy runs ok on a PC with 128M RAM, but I dream of getting it going on a 64M system. Puppy site: http://www.goosee.com/puppy Regards, Barry Kauler

Sept. 2, 2003

Re: [Dillo-dev] tight loop on IO error

by Jorge Arellano Cid

On Mon, 1 Sep 2003, Andreas Schweitzer wrote: > > All I did was fix the problem for me -- it's possible that there's > > still some object cleanup elsewhere that really needs doing ... > > It almost looks like that there needs some more digging. > > I did some tests comparing Linux and FreeBSD. > 1) The patch needs to be slightly modified for the Linux version, > otherwise dillo won't even start correctly :-) > 2a) When the timeout occurs while contacting unresponsive sites: > The Linux version actually stops eventually and puts > "ERROR: unable to connect to remote host" > in the status bar. However, none of the error debug > messgaes actually occur ... > 2b) Same as 2a but under FreeBSD: dillo still keeps > the "Contacting host" in the status bar, and the > stop-icon is still unfaded. And the error message > gets dumped as indicated in the patch. > > But I'm afraid the logic how all these routines are > accessed is a bit too compliacted for me right now :-) Hi! I just made a quick patch and tested http://primates.ximian.com/~miguel/all.html with a dialup on linux (no CPU hog, no problems, 80 of 83 images got). The idea was to make it analogous to IO_read(). Please test it under BSDs (it's on CVS). Cheers Jorge.-

Sept. 1, 2003

Re: [Dillo-dev] tight loop on IO error

by Phil Pennock

On 2003-09-01 at 16:38 +0200, Andreas Schweitzer wrote: > I did some tests comparing Linux and FreeBSD. > 1) The patch needs to be slightly modified for the Linux version, > otherwise dillo won't even start correctly :-) *blinks repeatedly* In that case, there's something happening on Linux where a write() at startup (cookie management, perhaps?) is failing the first time and succeeding later on, trying busily until it succeeds. This is the only thing that I can think of. Because the only _real_ change (ie: ignoring the cosmetic fluff to make the debugging easier on my eyes) was to change from: if (failure = a) { foo; /* break or continue or return */ } else if (failure = b) { bar; } to this: select(failure) { case a: foo; /* break or continue or return */ case b: bar; /* break or continue or return */ default: return FALSE; } This went on the theory that it's easier to spot that you need a default (and force yourself to always write a default handler) with the switch(){} syntax. I then went for the simplest handler. IF this changes behaviour from "appears to work" to "won't do X", then "X" relies upon repeatedly trying the write() inside a busy loop. Provided that the patch applied cleanly, that is. *shrugs* -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Sept. 1, 2003

Re: [Dillo-dev] tight loop on IO error

by Andreas Schweitzer

> All I did was fix the problem for me -- it's possible that there's > still some object cleanup elsewhere that really needs doing ... It almost looks like that there needs some more digging. I did some tests comparing Linux and FreeBSD. 1) The patch needs to be slightly modified for the Linux version, otherwise dillo won't even start correctly :-) 2a) When the timeout occurs while contacting unresponsive sites: The Linux version actually stops eventually and puts "ERROR: unable to connect to remote host" in the status bar. However, none of the error debug messgaes actually occur ... 2b) Same as 2a but under FreeBSD: dillo still keeps the "Contacting host" in the status bar, and the stop-icon is still unfaded. And the error message gets dumped as indicated in the patch. But I'm afraid the logic how all these routines are accessed is a bit too compliacted for me right now :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 1, 2003