- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]patch for bug 211

by Jorge Arellano Cid

On Wed, 9 Jun 2004, Diego Sáenz wrote: > El Wed, 9 Jun 2004 09:31:40 -0400 (CLT) > Jorge Arellano Cid <jcid(a)dillo.org> escribio: > > > > > > > On Sun, 6 Jun 2004, Diego Sáenz wrote: > > > > > Hello. > > > > Hi Diego. > > > Re, express pathes service for this 4 days (holidays in my place). :) :) > > > Here i send a patch for the dillo bug 211 (remember save dir on > > save and open dialogs) based on a pactch for an old version of > > dillo (0.6.¿?). it was made for 0.8.1 but apply in current cvs > > too. Each dillo window remember its own save dir. Sorry if this > > is not the right place to send patchs. > > > > Yes, that's an old need. When I first received the patch from > > Lars, I asked him to "Please make separate buffers for open and > > save". > > > > I do not see this expecially nedded, but sure it will be a dillo > own feature like the bugmeter. DONE I don't know how other browsers handle it. Sometimes I open test html files from one directory, and usually save downloaded files to /tmp or ~. > > > It'd be also good to make it browser wide (i.e. not per window), > > I agree whit this fully. DONE Good. Reviewed and commited. I removed a gcc warning, and made some polishing towards our coding standards and added a changelog entry. Please review the commited code from CVS. ¡Saludos! Jorge.-

June 9, 2004

[Dillo-dev]Re: Dillo: Bug#568

by David McKee

On Wed, 9 Jun 2004, Jorge Arellano Cid wrote: > There's: > > 568 > Impact: soft error > At: run time > Type: render bug > Comments: When a button tooltip is displayed, and you scroll the > page with the keyboard, dillo fails to render the newly exposed > content. This is the same behaviour reported for images in bug > 289. > HTReproduce: Open any page taller than the view area, place the > mouse over a dillo control, when the tool tip appears, scroll the > page with the keyboard. > WorkedBy: nobody > Submitter: dmckee*jlab*org > > in the bug track. I can't reproduce it, so maybe it's a GTK > problem. What version are you using? (BTW dillo 0.8.1 or CVS is > assumed). I track the CVS. It is still doing it for me. But this is in a fairly old evnrironment. Environment: RedHat 6.2 + this and that, custom kernel (2.2 series). egcs 2.91.66 <== same code base as gcc 2.95 glibc 2.1.3 gtk+ 1.2.6 XFree86 3.36 with a Mach64 based card. > I tried several pages, but for instance, going to our home > page, making the tooltip for bookmarks appear, and scrolling with > the keyboard works OK for me. Can anyone reproduce this bug? So, it is probably a detail in my setup. Anyone else seeing this? I'll look on one of my Debian 3.0 machine when I get a chance. -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

June 9, 2004

Re: [Dillo-dev]patch for bug 211

by Diego Sáenz

El Wed, 9 Jun 2004 09:31:40 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> escribio: > > > On Sun, 6 Jun 2004, Diego Sáenz wrote: > > > Hello. > > Hi Diego. > Re, express pathes service for this 4 days (holidays in my place). :) > > Here i send a patch for the dillo bug 211 (remember save dir on > save and open dialogs) based on a pactch for an old version of > dillo (0.6.¿?). it was made for 0.8.1 but apply in current cvs > too. Each dillo window remember its own save dir. Sorry if this > is not the right place to send patchs. > > Yes, that's an old need. When I first received the patch from > Lars, I asked him to "Please make separate buffers for open and > save". > I do not see this expecially nedded, but sure it will be a dillo own feature like the bugmeter. DONE > It'd be also good to make it browser wide (i.e. not per window), I agree whit this fully. DONE > and maybe add a "download_directory" entry to dillorc. The > latter doesn't seem urgent though, because we still don't have a > graphical dpi for downloads... > Maybe tomorrow. > Please make the suggested changes to the patch. > > Cheers > Jorge.- > > > PS: Feedback is welcome. Diego Sáenz/DarkSpirit

June 9, 2004

Re: [Dillo-dev]Dillo: Bug#568

by Jim Nutt

On Wed, 9 Jun 2004 09:52:44 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > in the bug track. I can't reproduce it, so maybe it's a GTK > problem. What version are you using? (BTW dillo 0.8.1 or CVS is > assumed). > > I tried several pages, but for instance, going to our home > page, making the tooltip for bookmarks appear, and scrolling with > the keyboard works OK for me. Can anyone reproduce this bug? If it helps, I can't reproduce it either (running CVS as of 6/8) -- jim nutt home: jim(a)nuttz.org jabber: jimnutt(a)jabber.com work: jimnutt(a)vestek.com ms msg: jim(a)nuttz.org pgp id: 1ECBCC78

June 9, 2004

[Dillo-dev]Dillo: Bug#568

by Jorge Arellano Cid

Hi, There's: 568 Impact: soft error At: run time Type: render bug Comments: When a button tooltip is displayed, and you scroll the page with the keyboard, dillo fails to render the newly exposed content. This is the same behaviour reported for images in bug 289. HTReproduce: Open any page taller than the view area, place the mouse over a dillo control, when the tool tip appears, scroll the page with the keyboard. WorkedBy: nobody Submitter: dmckee*jlab*org in the bug track. I can't reproduce it, so maybe it's a GTK problem. What version are you using? (BTW dillo 0.8.1 or CVS is assumed). I tried several pages, but for instance, going to our home page, making the tooltip for bookmarks appear, and scrolling with the keyboard works OK for me. Can anyone reproduce this bug? Cheers Jorge.-

June 9, 2004

Re: [Dillo-dev][전체회신] Re: [Dillo-dev]Downloads File

by Jorge Arellano Cid

Hi Vinod, On Fri, 26 Mar 2004 vinod(a)etri.re.kr wrote: > Hi Jorge > > > Hi all > Hi Vinod. > I assume you received my email, and after considering, you > decided to work on the GUI dpi for downloads. > (please confirm me that) > > # Yes. I did intend to confirm after reply from mailing list regarding work. Since then I haven't had any news about this. :-( Have you made some progress with the cleanup of the GUI dpi for downloads? Cheers Jorge.-

June 9, 2004

Re: [Dillo-dev]patch for bug 211

by Jorge Arellano Cid

On Sun, 6 Jun 2004, Diego Sáenz wrote: > Hello. Hi Diego. > Here i send a patch for the dillo bug 211 (remember save dir on save and open dialogs) based on a pactch for an old version of dillo (0.6.¿?). it was made for 0.8.1 but apply in current cvs too. Each dillo window remember its own save dir. Sorry if this is not the right place to send patchs. Yes, that's an old need. When I first received the patch from Lars, I asked him to "Please make separate buffers for open and save". It'd be also good to make it browser wide (i.e. not per window), and maybe add a "download_directory" entry to dillorc. The latter doesn't seem urgent though, because we still don't have a graphical dpi for downloads... Please make the suggested changes to the patch. Cheers Jorge.- PS: Feedback is welcome.

June 9, 2004

[Dillo-dev]Using alternate char for TABBING

by Deon Stoltz

I have recently discovered dillo and am delighted! Very fast and lightweight. We want to use if in a settop box application (thus the lightweight requirement). We need to interface to a IR remote control device so no keyboard are available. Web pages can normally be navigated with the TAB key. In our application we need to associate the TAB key with another key eg: ctrl-A. Do somebody know how, where to do this? I had a look in the code but I am not that strong on c++. ANY help will be appreciated! Thanks Deon

June 9, 2004

[Dillo-dev]Content outside table border

by Jorge Arellano Cid

Hi Sebastian, Just found this page: http://www.757.org/~joat/blog/ look at the small calendar! Best Jorge.-

June 9, 2004

Re: [Dillo-dev]Some remarks on the UI

by Jorge Arellano Cid

On Sun, 6 Jun 2004, Sebastian Geerken wrote: > Hi, > > I've just committed several changes, which fix the issues mentioned > here. Please test and report any bugs. If you are not sure, whether > you have detected a bug, it's certainly a misfeature, so report it > anyway :-) I reviewed the patch and commited some changes. Here go my comments: * I liked very much the new menu-title widget! * gcc showed some "missing initializer" warnings. It was the lack of the latest pointer in three GtkTypeInfo structures. Fixed. * The "." shortcut was not working. Fixed. * There was a warning for a signed/unsigned comparison, so I switched _GtkExtButton's pressed_button to guint. Fixed. * The "View Page Bugs" menu item for the page menu doesn't work. It went to a segfault once. NOT fixed. Some inside comments refer to unused code, for instance on Home and reload buttons. Yes, it was meant for future extensions (e.g. a reload images menu item). Now that there's a new way to code this (as with Back and Forward), the old way can be safely deleted. I changed the text for the tooltips of these buttons. Lots of mouses have two buttons and emulate the middle-click when both are pressed, so "right-click" and "middle-click" are a bit better than numbers in this case. It was nice to see the middle-click over "clear-url" button as a shortcut for paste. It'd be perfect if the entry can be focused at the same time. > > On Tue, Jun 01, Jorge Arellano Cid wrote: > > On Mon, 31 May 2004, Sebastian Geerken wrote: > > > 1. Bug meter: The bug meter button reacts on the "pressed" event, to > > > show the window, but it should react on the "clicked" signal. > > > Popping up a window after a "pressed" signal is usually only done > > > for volatile windows (like menus, or overview windows, like in > > > GIMP, which often vanish again, after releasing the mouse button). > > > > > > Reacting on "pressed" is always a bit problematic, also because the > > > pointer grab initiated with this event can cause side-effects. > > Fixed. > > > > Furthermore, it should not have a relief, compare to the "Hide > > > Controls" button. > > Also fixed, I've removed the relief. Yes, the toolbar icons and the "Hide controls" one are OK without a relief, but after watching how the bug-meter button looks without a relief, and how much it hints the user of being a button, I'd much prefer to have the relief back. Note that the "Hide controls" button has a drawed frame around that helps getting the idea of it being a button! Perhaps a more orthogonal way of doing it is to have a relief for both, but it's simpler to keep it as it was. > > > > 2. The menus behind the "Back" and "Forward" buttons: Consider the > > > following scenario: > > > > > > (i) The user presses button 3 on the "Back" button, and the menu > > > is shown. > > > > > > (ii) He keeps the button pressed, moves to one entry in the menu, > > > and releases the button. Nothing happens. > > > > > > Currently, the menu items only react on "button_press", which is > > > anyway wrong (see above). Furthermore, in this situation, the item > > > should already react on the "release" event, either as described > > > above, or in the way (i) click on menu, (ii) click on menu > > > entry. The current behaviour is that much confusing, that a user > > > may think that it does not work at all. (I did!) > > > > Yes. Sometime ago Ricardo Persichetti sent me a patch for this. > > It's just a couple of lines. Now on CVS for testing purposes, > > plus enhanced pixmaps for Back and Forward that hint their right > > click menus. > > I've written two new widgets, GtkExtMenu and GtkExtMenuItem, which > handle this in a cleaner way. Connecting to "button-release-event" has > several disadvantages, what I've seen until now, is: (i) keyboard > navigation was not handled, and (ii) the menu was hidden too late. > > The new widgets resemble the standard way as far as possible, so > problems shouldf be minimized. Good! > > > BTW, it is not very obvious, that there is a menu behind these two > > > buttons. Perhaps there should be, in the icon, a small arrow > > > directed downdwards, or so. > > > > Done! > > You forgot the small icons, this is fixed now. Also, I've added text > to the tooltips. Cute icons :) > > > 3. Attached is the incomplete code of a new widget, which changes the > > > behaviour of GtkButton: > > > > > > (i) It reacts also on button 2 and 3, this would make multiple > > > functions for one button possible. Actually, this feature > > > should be reserved for very few situation (since it is simply > > > confusing), namely the "Clear URL" button, which may also be > > > used for visiting the URL in the selection buffer. > > > > > > (ii) It provides a function for attaching a menu in a better way, > > > than we have currently, for the "Back" and "Forward" menus, > > > and for the bug meter. > > > > > > Simply copy all files into one directory, call "make", and run > > > "testprg". Look, what happens with different mouse buttons. > > > > Interesting. I went through the code a bit. > > > > It's not obvious to me how to modify them to be able to provide > > the same functionality (new window on middle click on history), > > and not to screw the design at the same time. > > Has been enhanced integrated (for forward, backward, and bug > meter). See comments in the code. Good work. It looks cleaner too. Cheers Jorge.-

June 8, 2004

[Dillo-dev]patch for bug 211

by Diego Sáenz

Hello. Here i send a patch for the dillo bug 211 (remember save dir on save and open dialogs) based on a pactch for an old version of dillo (0.6.¿?). it was made for 0.8.1 but apply in current cvs too. Each dillo window remember its own save dir. Sorry if this is not the right place to send patchs. DarkSpirit/Diego Sáenz

June 6, 2004

Re: [Dillo-dev]Some remarks on the UI

by Sebastian Geerken

On Sun, Jun 06, Sebastian Geerken wrote: > I've just committed several changes, which fix the issues mentioned > here. ... Just in case, that someone has already checked this out: There was a bug in the changes, which is fixed in the meanwhile. Sebastian

June 6, 2004

Re: [Dillo-dev]Some remarks on the UI

by Sebastian Geerken

Hi, I've just committed several changes, which fix the issues mentioned here. Please test and report any bugs. If you are not sure, whether you have detected a bug, it's certainly a misfeature, so report it anyway :-) On Tue, Jun 01, Jorge Arellano Cid wrote: > On Mon, 31 May 2004, Sebastian Geerken wrote: > > 1. Bug meter: The bug meter button reacts on the "pressed" event, to > > show the window, but it should react on the "clicked" signal. > > Popping up a window after a "pressed" signal is usually only done > > for volatile windows (like menus, or overview windows, like in > > GIMP, which often vanish again, after releasing the mouse button). > > > > Reacting on "pressed" is always a bit problematic, also because the > > pointer grab initiated with this event can cause side-effects. Fixed. > > Furthermore, it should not have a relief, compare to the "Hide > > Controls" button. Also fixed, I've removed the relief. > > 2. The menus behind the "Back" and "Forward" buttons: Consider the > > following scenario: > > > > (i) The user presses button 3 on the "Back" button, and the menu > > is shown. > > > > (ii) He keeps the button pressed, moves to one entry in the menu, > > and releases the button. Nothing happens. > > > > Currently, the menu items only react on "button_press", which is > > anyway wrong (see above). Furthermore, in this situation, the item > > should already react on the "release" event, either as described > > above, or in the way (i) click on menu, (ii) click on menu > > entry. The current behaviour is that much confusing, that a user > > may think that it does not work at all. (I did!) > > Yes. Sometime ago Ricardo Persichetti sent me a patch for this. > It's just a couple of lines. Now on CVS for testing purposes, > plus enhanced pixmaps for Back and Forward that hint their right > click menus. I've written two new widgets, GtkExtMenu and GtkExtMenuItem, which handle this in a cleaner way. Connecting to "button-release-event" has several disadvantages, what I've seen until now, is: (i) keyboard navigation was not handled, and (ii) the menu was hidden too late. The new widgets resemble the standard way as far as possible, so problems shouldf be minimized. > > BTW, it is not very obvious, that there is a menu behind these two > > buttons. Perhaps there should be, in the icon, a small arrow > > directed downdwards, or so. > > Done! You forgot the small icons, this is fixed now. Also, I've added text to the tooltips. > > 3. Attached is the incomplete code of a new widget, which changes the > > behaviour of GtkButton: > > > > (i) It reacts also on button 2 and 3, this would make multiple > > functions for one button possible. Actually, this feature > > should be reserved for very few situation (since it is simply > > confusing), namely the "Clear URL" button, which may also be > > used for visiting the URL in the selection buffer. > > > > (ii) It provides a function for attaching a menu in a better way, > > than we have currently, for the "Back" and "Forward" menus, > > and for the bug meter. > > > > Simply copy all files into one directory, call "make", and run > > "testprg". Look, what happens with different mouse buttons. > > Interesting. I went through the code a bit. > > It's not obvious to me how to modify them to be able to provide > the same functionality (new window on middle click on history), > and not to screw the design at the same time. Has been enhanced integrated (for forward, backward, and bug meter). See comments in the code. Sebastian

June 6, 2004

[Dillo-dev]Bug Meter suggestion

by Kyle Amon

Suggestion: On of the bullet items under the "What can I do?" section of the new "About Dillo's Bug Meter" page (http://www.dillo.org/help/bug_meter.html) is ... * Help page authors and webmasters to provide standards-compliant contents (For instance, you can copy&paste the error messages produced by Dillo, and mail them to the author). While a nice idea in theory, almost no one is likely to do such a thing nearly as often as one encounters bugs in websites since it would entail one spend most of their browser time sanitizing the web rather than surfing it. Therefore, to facilitate such activity in a manner the user is likely to engage in, I suggest this be made an automatic dillo option (perhaps even the default behavior). In other words, have dillo automatically email these error messages to webmaster(a)wwwdomain.com so the user doesn't have to do so manually. Since computers are unbothered by the same monotony humans usually don't have much time for anyway, let the computer [via dillo] do the work here. At the very least, along side the W3C and WDG validator links in the Bug Meter, a link/exec to send such an email should be provided. If it isn't convienient (at the very least), people won't do it. -- Kyle P.S. I, for one, do about 75% of my browsing in dillo and would be happy to enable such a feature to nag lousy webmasters about their drift toward fascism in html if it were automatic. Beyond that, I might use a handy click/link/exec once in a while, but I doub't I'd ever send such a nag manually, much less often... and I'm pretty sure I'm not too unique in this regard. -- Kyle Amon email: amonk(a)gnutec.com url: http://www.gnutec.com/~amonk/ KeyID 1024D/4EB96E44 Fingerprint = E9EC 0046 8487 23D7 C91C D757 7B2A 8AE9 4EB9 6E44 "The free man is not anti-American, but anti-imperial. America [now] revisits the time of colonizers drunk on their superiority, convinced of their liberating mission, and counting on reimbursing themselves directly." -- Regis Debray This email Copyright 2004 by Kyle Amon, Inc., a Florida corporation, 12032 Colonial Estates Lane, Riverview, FL 33569-6894: +1 (813) 689-4041 amonk(a)gnutec.com http://www.gnutec.com/~amonk/. All rights reserved.

June 5, 2004

Re: [Dillo-dev]UTF-8

by Maarten Sander

Hi, > Please let me know if you know of more pages like this one, or > if you know the rationale for preferring UTF-8 over latin1 when > the latter is enough. Well, I guess it's the 'pretty' quotes they use on the webpage. Those curly quotes are not part of your normal latin1 character set, but are part of UTF-8 (and also Windows-1252 IIRC). It's also useful when display foreign names in your articles; see for example the site of a client of ours: http://www.codart.nl/ -- they use a lot of non-English names and titles there. Regards, Maarten

June 4, 2004

[Dillo-dev]UTF-8

by Jorge Arellano Cid

Hi guys! I just added a small hack to view UTF-8-encoded quotation marks. Yes, it's a mistery to me why someone would want to serve pages in english, encoded in UTF-8 instead of Latin1. ...but you may find some as this one: http://www.seattleweekly.com/features/0422/040602_news_microsoft.php Please let me know if you know of more pages like this one, or if you know the rationale for preferring UTF-8 over latin1 when the latter is enough. Cheers Jorge.-

June 3, 2004

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)

by Sebastian Geerken

On Wed, Jun 02, Jorge Arellano Cid wrote: > With regard to the new widget for buttons, and the inminence of > 0.8.2 release, if you like it could be the last enhancement > before the release (I'd also add the context-menu indicator to > the bug-meter pixmaps). Yes, I think it should be finished within a few days (Sunday or so). Sebastian

June 3, 2004

Re: [Dillo-dev][bug] ppc64 crash on right-click / bug tracking system

by Jorge Arellano Cid

On Thu, 3 Jun 2004, Thomas Cort wrote: > Hi, Hi! > I ran into a problem where dillo crashes when I right click on any > part of a webpage. A full bug report is below this paragraph. When I > went to use the bug tracking system I noticed the "Max 256 chars" > notice. Is it possible to get this increased? I couldn't get my bug > report into <= 256 characters. The <=256 limit is to keep things concise. It helps developers a lot to skim all the bugs when reviewing the bugtrack... Of course there're times when this is not possible (just a few in four years!), and you can resort to the mailing list. > > Dillo 0.8.1 on GNU/Linux (yellowdog 3.0) ppc64 (Apple G5) > > configure options: > --prefix=/home1/students/tcort > > To reproduce bug: > ssh with X11 forwarding and compression turned on, start dillo, and > right click on any part of the webpage. > > Notes: > I don't have local access to this machine, so I don't know if it's an > X11 forwarding bug or a ppc64 specific bug. Browsing webpages works > fine as long as you don't right click. Using other programs with X11 > forwarding from this machine, such as gimp, work fine. > > Output: > tcort@pepsi tcort $ ssh -X -C turing.ubishops.ca > tcort(a)turing.ubishops.ca's password: > [tcort@turing tcort]$ bin/dillo > dillo_dns_init: Here we go! > Disabling cookies. > Nav_open_url: Url=>about:splash< > Gdk-ERROR **: BadWindow (invalid Window parameter) > serial 2306 error_code 3 request_code 38 minor_code 0 > Gdk-ERROR **: BadAccess (attempt to access private resource denied) > serial 2307 error_code 10 request_code 102 minor_code 0 > [tcort@turing tcort]$ I recognize not to have a clue about this problem, but... > Gdk-ERROR **: BadAccess (attempt to access private resource denied) looks as we have a permission problem here. A google search for: "Gdk-ERROR **: BadAccess (attempt to access private resource denied)" led to: http://www.cygwin.com/ml/cygwin-xfree/2004-04/msg00348.html It seems that you need to use the "-Y" switch instead of "-X". Read the thread for details and tell us how it went. Cheers Jorge.-

June 3, 2004

[Dillo-dev][bug] ppc64 crash on right-click / bug tracking system

by Thomas Cort

Hi, I ran into a problem where dillo crashes when I right click on any part of a webpage. A full bug report is below this paragraph. When I went to use the bug tracking system I noticed the "Max 256 chars" notice. Is it possible to get this increased? I couldn't get my bug report into <= 256 characters. Dillo 0.8.1 on GNU/Linux (yellowdog 3.0) ppc64 (Apple G5) configure options: --prefix=/home1/students/tcort To reproduce bug: ssh with X11 forwarding and compression turned on, start dillo, and right click on any part of the webpage. Notes: I don't have local access to this machine, so I don't know if it's an X11 forwarding bug or a ppc64 specific bug. Browsing webpages works fine as long as you don't right click. Using other programs with X11 forwarding from this machine, such as gimp, work fine. Output: tcort@pepsi tcort $ ssh -X -C turing.ubishops.ca tcort(a)turing.ubishops.ca's password: [tcort@turing tcort]$ bin/dillo dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Gdk-ERROR **: BadWindow (invalid Window parameter) serial 2306 error_code 3 request_code 38 minor_code 0 Gdk-ERROR **: BadAccess (attempt to access private resource denied) serial 2307 error_code 10 request_code 102 minor_code 0 [tcort@turing tcort]$

June 3, 2004

Re: [Dillo-dev]Some remarks on the UI

by Sebastian Geerken

On Wed, Jun 02, Jorge Arellano Cid wrote: > On Wed, 2 Jun 2004, Sebastian Geerken wrote: > > Using the middle button on menu entries should probably be possible, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > perhaps we'll have to write a new widget for it, as I did with > > GtkButton. However, the new behaviour should be an extension to the > > standard, while the current behaviour is IMO very unusable. > > Note: I don't mean to be able to pop-up the history menu with > the middle button, but to have the option of middle-clicking its ^^^^^^^^^^^^^^^^^^^ > entry to open a new window or tab. ^^^^^ Yes, this is also what I mean. Sebastian

June 2, 2004

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)

by Jorge Arellano Cid

On Wed, 2 Jun 2004, Sebastian Geerken wrote: > On Tue, Jun 01, Jorge Arellano Cid wrote: > > On Mon, 31 May 2004, Sebastian Geerken wrote: > > > Scrolling half a page is actually standard behaviour of Gtk, look > > > e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or > > > less responsible for this in our case, since our code uses > > > GdkAdjustment::page_increment, which is set there. > > > > > > The attached patch "solves" it, but I'm not sure, wether the standard > > > behaviour should be overridden. > > > > Hmmmm well, from time to time I find the current behaviour less > > useful than a full page scroll. I don't know the rationale for a > > half page scroll in gtklayout either, but it looks as though a > > full page scroll would be a good default. > > This is somehow adopted by other widgets as well, I'm not sure what > other X programs do. Anyway, I don't care much about, apply it, if you > want the behaviour changed. Ok, done. I just used: 0.96 * allocation->height to allow for an overlapping of roughly one line. Comments welcome. > > > > It will probably still take some time, it is a bit more difficult than > > > I thought. > > > > Should I wait a bit for a new version? > > Don't wait on me. I'm currently not able to tell when I'm finished. > > > > PS: I'm currently working on huge changes in Dw, so committing patches > > > to Dw shold currently avoided when possible. > > In some cases, smaller patches may be applied; if merging fails, I'll > have to adjust it by hand. Anyway, I'd like to be explicitly told > about the changes, so I can better react on it. With regard to the new widget for buttons, and the inminence of 0.8.2 release, if you like it could be the last enhancement before the release (I'd also add the context-menu indicator to the bug-meter pixmaps). Cheers Jorge.-

June 2, 2004

Re: [Dillo-dev]Some remarks on the UI

by Jorge Arellano Cid

On Wed, 2 Jun 2004, Sebastian Geerken wrote: > On Tue, Jun 01, Jorge Arellano Cid wrote: > > On Mon, 31 May 2004, Sebastian Geerken wrote: > > > 1. Bug meter: The bug meter button reacts on the "pressed" event, to > > > show the window, but it should react on the "clicked" signal. > > > Popping up a window after a "pressed" signal is usually only done > > > for volatile windows (like menus, or overview windows, like in > > > GIMP, which often vanish again, after releasing the mouse button). > > > > > > Reacting on "pressed" is always a bit problematic, also because the > > > pointer grab initiated with this event can cause side-effects. > > > > > > Furthermore, it should not have a relief, compare to the "Hide > > > Controls" button. > > > > No problem. I even don't know why "clicked" should be used > > instead of "release" :-). I just copied the code from the menus. > > Note that the same code for the bug-meter button is used to > > handle the bug-meter menu entry in the "page menu". > > In most cases, the most "abstract" events should be used, i.e. > "clicked" for buttons, and "activate" for menu entries. Thanks for the tip! > > If a new implementation acts the same as the current one, from > > the user's point of view, it's perfect for me. > > If should act different! The bugmeter window should be shown as soon > as the user *releases* the button (as always). Yes, I meant that, but failed to explain it properly. ;) > > [...] > > > (The implementation would become a bit tricky, since button 2 will > > > pop up the page in a new window. Perhaps, I'd even suggest to skip > > > this feature, if a clean solution is not possible.) > > > > I use this feature all the time! > > > > Before switching to fluxbox, it was quite handy to spawn new > > dillo windows, and now, under fluxbox, it's perfect for making > > new TABS. > > Using the middle button on menu entries should probably be possible, > perhaps we'll have to write a new widget for it, as I did with > GtkButton. However, the new behaviour should be an extension to the > standard, while the current behaviour is IMO very unusable. Note: I don't mean to be able to pop-up the history menu with the middle button, but to have the option of middle-clicking its entry to open a new window or tab. > > > > 3. Attached is the incomplete code of a new widget, which changes the > > > behaviour of GtkButton: > > > > > > (i) It reacts also on button 2 and 3, this would make multiple > > > functions for one button possible. Actually, this feature > > > should be reserved for very few situation (since it is simply > > > confusing), namely the "Clear URL" button, which may also be > > > used for visiting the URL in the selection buffer. > > > > > > (ii) It provides a function for attaching a menu in a better way, > > > than we have currently, for the "Back" and "Forward" menus, > > > and for the bug meter. > > > > > > Simply copy all files into one directory, call "make", and run > > > "testprg". Look, what happens with different mouse buttons. > > > > Interesting. I went through the code a bit. > > > > It's not obvious to me how to modify them to be able to provide > > the same functionality (new window on middle click on history), > > and not to screw the design at the same time. > > I'll look at it later. Ok. Cheers Jorge.-

June 2, 2004

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by Jorge Arellano Cid

On Wed, 2 Jun 2004, Madis Janson wrote: > > On Tue, 1 Jun 2004, Jorge Arellano Cid wrote: > > > The current prototype for SSL (using dpi) provides for an easy > > way of implementing connection caching, and for asking the user > > (using dillo's API) whether to continue on unverified > > connections, the SSL part of this verification is not yet done > > though. > > > > As Madis put it: > > > > > Most important thing missing from the ssl specific code is certificate > > > verification - it MUST be done in order to have any actual security. > > > In its current form it just gives a way to access SSL sites, but not > > > secure access. > > > > I know people look forward to the day when they can complete > > their online shopping with dillo, but we must be very careful to > > provide real security. This is key. > > I hope to look at it (probably in july). Good! > > Unfortunately I'm not an encryption expert, and we need some > > help from a savvy guy (the chances of a SSL freshman to make > > mistakes is very high). > > Yes, it is a hard thing. There were for example a same SSL certification > chain handling bug in IE and Konqueror. > > It would help, when someone would write a library-like code for verifing > peers certificate with simple interface. I'd look the existing > implementations in Konqueror SSL plugin and Mozilla for reference. I read a lot of the GnuTLS manual, and found some interesting facts and functions that could help. Including a function somewhat like what you sketched: > For example something similar to this: > > /** > * Check the peer's certificate. > * > * \param connection current SSL connection > * \param result the verifications result > * 0 - ok > * 1 - we don't know wtf it is, ask confirmation > * and tell user, that good answer is NO. > * 2 - error, couldn't do the verification > * .... > * \return message for user > */ > char* chain_verify(SSL *connection, int *result); > > /** > * User said, that he likes that one... > * > * \param cert certificate to remember > * \return 0 - error (message in openssl error stack), 1 - OK > */ > int remember_certificate(X509 *cert); > > > > I'd love to have a TLS based dpi for https (TLS lib is GPLed > > and is a requisite to NPTL, so it'll become as ubiquitous as SSL > > lib). The current prototype is SSLlib based, but is enough to > > start polishing and extending the code. > > > > Some time ago Madis wrote an SSL gateway for Dillo. After some > > work, I decided to integrate it through the dpi framework (to > > empower it with dpip and also to avoid some quirks by using the > > standard way to extend dillo). That is the current prototype. > > http://www.zone.ee/myzz/dillo/https_dpi/https_dpi.tar.gz > Here follos an abridgment of interesting information inside the GnuTLS manual: <q> http://www.gnu.org/software/gnutls/manual/gnutls/gnutls.html -- Description: Technically GnuTLS is a portable ANSI C based library which implements the TLS 1.0/1.1 and SSL 3.0 protocols, accompanied with the required framework for authentication and public key infrastructure. The library is available under the GNU Lesser GPL license1.2. Important features of the GnuTLS library include: * Support for TLS 1.0, TLS 1.1 and SSL 3.0 protocols. * Support for both X.509 and OpenPGP certificates. * Support for handling and verification of certificates. * Support for SRP for TLS authentication. * Support for TLS Extension mechanism. * Support for TLS Compression Methods. Additionally GnuTLS provides a limited emulation API for the widely used OpenSSL1.3 library, to ease integration with existing applications. --- Verifying peer's certificate A TLS session is not secure just after the handshake procedure has finished. It must be considered secure, only after the peer's certificate and identity have been verified. That is, you have to verify the signature in peer's certificate, the hostname in the certificate, and expiration dates. Just after this step you should treat the connection as being a secure one. The following function is a simple example on how to verify a single certificate. Real world programs should be able to handle certificate chains as well. --- /* This function will try to verify the peer's certificate, and * also check if the hostname matches, and the activation, expiration dates. */ void verify_certificate(gnutls_session session, const char* hostname) [...] --- Resuming Sessions: The gnutls_handshake function, is expensive since a lot of calculations are performed. In order to support many fast connections to the same server a client may use session resuming. Session resuming is a feature of the TLS protocol which allows a client to connect to a server, after a successful handshake, without the expensive calculations. This is achieved by using the previously established keys. GnuTLS supports this feature, and the example resume client illustrates a typical use of it. --- http://msmtp.sourceforge.net/ (GPL) Version 1.0.0: - correctly handle certificate chains in tls.c GnuTLS code --- Interview (Nikos Mavroyanopoulos): http://www.gnu-friends.org/story/2003/12/17/14525/717 </q> Some remarks: The msmtp project is interesting because is GPLed, and handles certificate chains, so it can be reused. The "Resuming Sessions" feature is also interesting because it could initially account for what we've been calling "connection caching". (i.e. instead of keeping an SSL socket alive to communicate with the server, a new session can be requested, and GnuTLS' "resuming sessions" does the rest). The documentation is clear and comes with several examples. Please give it a look Madis. Cheers Jorge.-

June 2, 2004

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)

by Sebastian Geerken

On Tue, Jun 01, Jorge Arellano Cid wrote: > On Mon, 31 May 2004, Sebastian Geerken wrote: > > Scrolling half a page is actually standard behaviour of Gtk, look > > e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or > > less responsible for this in our case, since our code uses > > GdkAdjustment::page_increment, which is set there. > > > > The attached patch "solves" it, but I'm not sure, wether the standard > > behaviour should be overridden. > > Hmmmm well, from time to time I find the current behaviour less > useful than a full page scroll. I don't know the rationale for a > half page scroll in gtklayout either, but it looks as though a > full page scroll would be a good default. This is somehow adopted by other widgets as well, I'm not sure what other X programs do. Anyway, I don't care much about, apply it, if you want the behaviour changed. > > It will probably still take some time, it is a bit more difficult than > > I thought. > > Should I wait a bit for a new version? Don't wait on me. I'm currently not able to tell when I'm finished. > > PS: I'm currently working on huge changes in Dw, so committing patches > > to Dw shold currently avoided when possible. In some cases, smaller patches may be applied; if merging fails, I'll have to adjust it by hand. Anyway, I'd like to be explicitly told about the changes, so I can better react on it. Sebastian

June 2, 2004

Re: [Dillo-dev]Some remarks on the UI

by Sebastian Geerken

On Tue, Jun 01, Jorge Arellano Cid wrote: > On Mon, 31 May 2004, Sebastian Geerken wrote: > > 1. Bug meter: The bug meter button reacts on the "pressed" event, to > > show the window, but it should react on the "clicked" signal. > > Popping up a window after a "pressed" signal is usually only done > > for volatile windows (like menus, or overview windows, like in > > GIMP, which often vanish again, after releasing the mouse button). > > > > Reacting on "pressed" is always a bit problematic, also because the > > pointer grab initiated with this event can cause side-effects. > > > > Furthermore, it should not have a relief, compare to the "Hide > > Controls" button. > > No problem. I even don't know why "clicked" should be used > instead of "release" :-). I just copied the code from the menus. > Note that the same code for the bug-meter button is used to > handle the bug-meter menu entry in the "page menu". In most cases, the most "abstract" events should be used, i.e. "clicked" for buttons, and "activate" for menu entries. > If a new implementation acts the same as the current one, from > the user's point of view, it's perfect for me. If should act different! The bugmeter window should be shown as soon as the user *releases* the button (as always). > [...] > > (The implementation would become a bit tricky, since button 2 will > > pop up the page in a new window. Perhaps, I'd even suggest to skip > > this feature, if a clean solution is not possible.) > > I use this feature all the time! > > Before switching to fluxbox, it was quite handy to spawn new > dillo windows, and now, under fluxbox, it's perfect for making > new TABS. Using the middle button on menu entries should probably be possible, perhaps we'll have to write a new widget for it, as I did with GtkButton. However, the new behaviour should be an extension to the standard, while the current behaviour is IMO very unusable. > > 3. Attached is the incomplete code of a new widget, which changes the > > behaviour of GtkButton: > > > > (i) It reacts also on button 2 and 3, this would make multiple > > functions for one button possible. Actually, this feature > > should be reserved for very few situation (since it is simply > > confusing), namely the "Clear URL" button, which may also be > > used for visiting the URL in the selection buffer. > > > > (ii) It provides a function for attaching a menu in a better way, > > than we have currently, for the "Back" and "Forward" menus, > > and for the bug meter. > > > > Simply copy all files into one directory, call "make", and run > > "testprg". Look, what happens with different mouse buttons. > > Interesting. I went through the code a bit. > > It's not obvious to me how to modify them to be able to provide > the same functionality (new window on middle click on history), > and not to screw the design at the same time. I'll look at it later. > BTW, are you working on the layering API of Dw we need to go > FLTK? > > I ask because we may have to look at it again when re-making > the UI for FLTK. Yes. It got a bit complicated, since in the old design, DwWidget and DwGtkViewport interacted very tightly, and DwWidget assumed too much about DwGtkViewport. Anyway (in case anybody thinks that a port could be simpler :-), as I already stated, this redesign is rather useful for the future, not only for the port (and it increases the code quality, since it reduces dependencies). Sebastian

June 2, 2004

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by Madis Janson

On Tue, 1 Jun 2004, Jorge Arellano Cid wrote: > The current prototype for SSL (using dpi) provides for an easy > way of implementing connection caching, and for asking the user > (using dillo's API) whether to continue on unverified > connections, the SSL part of this verification is not yet done > though. > > As Madis put it: > > > Most important thing missing from the ssl specific code is certificate > > verification - it MUST be done in order to have any actual security. > > In its current form it just gives a way to access SSL sites, but not > > secure access. > > I know people look forward to the day when they can complete > their online shopping with dillo, but we must be very careful to > provide real security. This is key. I hope to look at it (probably in july). > Unfortunately I'm not an encryption expert, and we need some > help from a savvy guy (the chances of a SSL freshman to make > mistakes is very high). Yes, it is a hard thing. There were for example a same SSL certification chain handling bug in IE and Konqueror. It would help, when someone would write a library-like code for verifing peers certificate with simple interface. I'd look the existing implementations in Konqueror SSL plugin and Mozilla for reference. For example something similar to this: /** * Check the peer's certificate. * * \param connection current SSL connection * \param result the verifications result * 0 - ok * 1 - we don't know wtf it is, ask confirmation * and tell user, that good answer is NO. * 2 - error, couldn't do the verification * .... * \return message for user */ char* chain_verify(SSL *connection, int *result); /** * User said, that he likes that one... * * \param cert certificate to remember * \return 0 - error (message in openssl error stack), 1 - OK */ int remember_certificate(X509 *cert); > I'd love to have a TLS based dpi for https (TLS lib is GPLed > and is a requisite to NPTL, so it'll become as ubiquitous as SSL > lib). The current prototype is SSLlib based, but is enough to > start polishing and extending the code. > > Some time ago Madis wrote an SSL gateway for Dillo. After some > work, I decided to integrate it through the dpi framework (to > empower it with dpip and also to avoid some quirks by using the > standard way to extend dillo). That is the current prototype. http://www.zone.ee/myzz/dillo/https_dpi/https_dpi.tar.gz But if someone knowledgeable of crypto, SSL and TLS library goes to write the TLS version of it, do it (and tell the list). I do not know the TLS library by myself.

June 2, 2004

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by robert w hall

In article <Pine.LNX.4.58.0406012204150.740(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > >On Sun, 30 May 2004, robert w hall wrote: > >> Every time I read the playstation2-linux lists I realise how very useful >> dillo will be when it gets just a little further. > > Please elaborate a bit on this subject. Well it's a lovely browser for that sort of machine (300MHz MIPS R5900 processor, 32MB of RAM), and I usually recommend anyone who is asking on the official site (www.playstation2-linux.com) to go get a copy in preference to, or at least along with, the gargantuan firefox. But it's a bit hard to have to tell a newbie that he won't actually be able to use dillo to post back to the same site he's reading from (needs SSL to post). They usually just go off and use firefox and s*d the disc thrashing! It doesn't need to be a very secure implementation (though I note and respect your reasoning here) - there was a patch available all though the 0.6 and 0.7 series which I think usually got implemented in the pre- compiled dillo downloads at the ps2 site... With the recent dropping in price of the ps2-linux kit, there are quite a few new-starters, who are trying to see what they can use on the net, and so a slightly-extended dillo would (IMHO) be very timely. Bob -- robert w hall

June 2, 2004

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by Jorge Arellano Cid

On Sun, 30 May 2004, robert w hall wrote: > Every time I read the playstation2-linux lists I realise how very useful > dillo will be when it gets just a little further. Please elaborate a bit on this subject. > How's the short/medium term future of https looking?(*) > If an official plugin is in the offing then that's probably what we > should all wait for. The short term looks very good, at this time we only need some TLS or SSLlib savvy guys, with some time willing to polish our current prototype. The main problem with the past prototypes and patches is that they don't handle connection caching (nor provided for an easy way to implement that), and the most important, they don't do certificate validation! The current prototype for SSL (using dpi) provides for an easy way of implementing connection caching, and for asking the user (using dillo's API) whether to continue on unverified connections, the SSL part of this verification is not yet done though. As Madis put it: > Most important thing missing from the ssl specific code is certificate > verification - it MUST be done in order to have any actual security. > In its current form it just gives a way to access SSL sites, but not > secure access. I know people look forward to the day when they can complete their online shopping with dillo, but we must be very careful to provide real security. This is key. Unfortunately I'm not an encryption expert, and we need some help from a savvy guy (the chances of a SSL freshman to make mistakes is very high). I'd love to have a TLS based dpi for https (TLS lib is GPLed and is a requisite to NPTL, so it'll become as ubiquitous as SSL lib). The current prototype is SSLlib based, but is enough to start polishing and extending the code. Some time ago Madis wrote an SSL gateway for Dillo. After some work, I decided to integrate it through the dpi framework (to empower it with dpip and also to avoid some quirks by using the standard way to extend dillo). That is the current prototype. Just in case an SSL/TLS savvy person is reading: the work with the dpi is quite simple, you don't need to know about Dillo's internal working, actually the https dpi is a C program that's independent of Dillo. The dpi just needs to make the secure connection to the remote server (and verify the cerificate), then forward the http stream to dillo, or ask whether to close or proceed when it can't verify. This is done with a simple dpid tag, all the SSL stuff happens inside the dpi. > Otherwise, is the patch from 0.7 resurrectable?? Sure, but not worth. At least the current prototype can POST. Cheers Jorge.-

June 2, 2004

Re: [Dillo-dev]Some remarks on the UI

by Jorge Arellano Cid

On Mon, 31 May 2004, Sebastian Geerken wrote: > Hi, > > several remarks on the UI, which should be fixed IMO. > > 1. Bug meter: The bug meter button reacts on the "pressed" event, to > show the window, but it should react on the "clicked" signal. > Popping up a window after a "pressed" signal is usually only done > for volatile windows (like menus, or overview windows, like in > GIMP, which often vanish again, after releasing the mouse button). > > Reacting on "pressed" is always a bit problematic, also because the > pointer grab initiated with this event can cause side-effects. > > Furthermore, it should not have a relief, compare to the "Hide > Controls" button. No problem. I even don't know why "clicked" should be used instead of "release" :-). I just copied the code from the menus. Note that the same code for the bug-meter button is used to handle the bug-meter menu entry in the "page menu". If a new implementation acts the same as the current one, from the user's point of view, it's perfect for me. > > 2. The menus behind the "Back" and "Forward" buttons: Consider the > following scenario: > > (i) The user presses button 3 on the "Back" button, and the menu > is shown. > > (ii) He keeps the button pressed, moves to one entry in the menu, > and releases the button. Nothing happens. > > Currently, the menu items only react on "button_press", which is > anyway wrong (see above). Furthermore, in this situation, the item > should already react on the "release" event, either as described > above, or in the way (i) click on menu, (ii) click on menu > entry. The current behaviour is that much confusing, that a user > may think that it does not work at all. (I did!) Yes. Sometime ago Ricardo Persichetti sent me a patch for this. It's just a couple of lines. Now on CVS for testing purposes, plus enhanced pixmaps for Back and Forward that hint their right click menus. > (The implementation would become a bit tricky, since button 2 will > pop up the page in a new window. Perhaps, I'd even suggest to skip > this feature, if a clean solution is not possible.) I use this feature all the time! Before switching to fluxbox, it was quite handy to spawn new dillo windows, and now, under fluxbox, it's perfect for making new TABS. > BTW, it is not very obvious, that there is a menu behind these two > buttons. Perhaps there should be, in the icon, a small arrow > directed downdwards, or so. Done! > > 3. Attached is the incomplete code of a new widget, which changes the > behaviour of GtkButton: > > (i) It reacts also on button 2 and 3, this would make multiple > functions for one button possible. Actually, this feature > should be reserved for very few situation (since it is simply > confusing), namely the "Clear URL" button, which may also be > used for visiting the URL in the selection buffer. > > (ii) It provides a function for attaching a menu in a better way, > than we have currently, for the "Back" and "Forward" menus, > and for the bug meter. > > Simply copy all files into one directory, call "make", and run > "testprg". Look, what happens with different mouse buttons. Interesting. I went through the code a bit. It's not obvious to me how to modify them to be able to provide the same functionality (new window on middle click on history), and not to screw the design at the same time. > Comments welcome. BTW, are you working on the layering API of Dw we need to go FLTK? I ask because we may have to look at it again when re-making the UI for FLTK. Best Jorge.-

June 1, 2004

Re: [Dillo-dev]dillo as a debian package ..?

by Mattias Östergren

On Tue, 1 Jun 2004 08:39:47 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Mon, 31 May 2004, Mattias Östergren wrote: > > > On Sun, 30 May 2004 11:38:55 -0400 (CLT) Jorge Arellano Cid > > <jcid(a)dillo.org> wrote: > > > > > > > > > > > On Tue, 25 May 2004, Willem van Engen wrote: > > > > > > > Hi all, > > > > > > > > ok, I made a new .deb for 0.8.1 and setup an apt repository on > > > > http://willem.engen.nl/debian > > > > please read debian install instructions there. I did only some > > > > very basic tests and seems to work nicely. Please report if I > > > > missed something. > > > > > > Thanks a lot Willem! > > > > > > I asked a couple of persons to try it, and added a link from > > > the download page. > > > > > > If someone can help with the official package, it'd be very > > > good too... > > > > > > > The official package is now up-to-date. > > > > /Mattias, Debian user. > > Good! > > I updated the download page accordingly. > > BTW, did you update the package? > Is this the same package Willem made? > > Cheers > Jorge.- > Phil Blundell updated it, and I don't think it's the same as Willem's, but I'm not sure. /Mattias

June 1, 2004

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)

by Jorge Arellano Cid

On Mon, 31 May 2004, Sebastian Geerken wrote: > On Sun, May 30, Jorge Arellano Cid wrote: > > On Fri, 28 May 2004, Brian Hechinger wrote: > > > so far, it's perfect for me. the only thing that i have a question about is > > > PgUp and PgDn only moving half a page at a time. is there a way to get them > > > to move a full page? > > > > Some time ago there was a patch, that i'd gladly apply, for > > that. Maybe Sebastian has it. I'm not sure. Sebastian? > > Scrolling half a page is actually standard behaviour of Gtk, look > e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or > less responsible for this in our case, since our code uses > GdkAdjustment::page_increment, which is set there. > > The attached patch "solves" it, but I'm not sure, wether the standard > behaviour should be overridden. Hmmmm well, from time to time I find the current behaviour less useful than a full page scroll. I don't know the rationale for a half page scroll in gtklayout either, but it looks as though a full page scroll would be a good default. > [later you wrote] > > It will probably still take some time, it is a bit more difficult than > I thought. Should I wait a bit for a new version? > PS: I'm currently working on huge changes in Dw, so committing patches > to Dw shold currently avoided when possible. No problem! I want to make a dillo-0.8.2 release real soon. The main reason is that the previous releasse announcement caught freshmeat in the middle of a HW upgrade. When finally they brought back the site, the pending announcements went almost unnoticed (roughly 30 times less visibility!). Cheers Jorge.-

June 1, 2004

Re: [Dillo-dev]Some remarks on the UI

by Nicola Girardi

This is what I replied privately to Sebastian: > BTW, it is not very obvious, that there is a menu behind these two > buttons. Perhaps there should be, in the icon, a small arrow > directed downdwards, or so. In fact I didn't ever discovered there was such (useful) menu. :-( > (ii) It provides a function for attaching a menu in a better way, > than we have currently, for the "Back" and "Forward" menus, > and for the bug meter. Another menu I didn't catch, the bug meter menu. :-) > Comments welcome. Very nice. :-)

June 1, 2004

Re: [Dillo-dev]dillo as a debian package ..?

by Jorge Arellano Cid

On Mon, 31 May 2004, Mattias Östergren wrote: > On Sun, 30 May 2004 11:38:55 -0400 (CLT) Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > > > > > > On Tue, 25 May 2004, Willem van Engen wrote: > > > > > Hi all, > > > > > > ok, I made a new .deb for 0.8.1 and setup an apt repository on > > > http://willem.engen.nl/debian > > > please read debian install instructions there. I did only some very > > > basic tests and seems to work nicely. Please report if I missed > > > something. > > > > Thanks a lot Willem! > > > > I asked a couple of persons to try it, and added a link from > > the download page. > > > > If someone can help with the official package, it'd be very > > good too... > > > > The official package is now up-to-date. > > /Mattias, Debian user. Good! I updated the download page accordingly. BTW, did you update the package? Is this the same package Willem made? Cheers Jorge.-

June 1, 2004

Re: [Dillo-dev]dillo as a debian package ..?

by Mattias Östergren

On Sun, 30 May 2004 11:38:55 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Tue, 25 May 2004, Willem van Engen wrote: > > > Hi all, > > > > ok, I made a new .deb for 0.8.1 and setup an apt repository on > > http://willem.engen.nl/debian > > please read debian install instructions there. I did only some very > > basic tests and seems to work nicely. Please report if I missed > > something. > > Thanks a lot Willem! > > I asked a couple of persons to try it, and added a link from > the download page. > > If someone can help with the official package, it'd be very > good too... > The official package is now up-to-date. /Mattias, Debian user.

May 31, 2004

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)

by Sebastian Geerken

On Mon, May 31, Brian Hechinger wrote: > On Mon, May 31, 2004 at 03:09:03PM +0200, Sebastian Geerken wrote: > > > > Scrolling half a page is actually standard behaviour of Gtk, look > > e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or > > less responsible for this in our case, since our code uses > > GdkAdjustment::page_increment, which is set there. > > hmmmmmm. can't say i care for that behavior. maybe i should whine to the GTK > folks and see if i can either get that changed, or at least get it setup so > there is some way to override it at run/compile time? They won't probably change it, especially since dillo depends on Gtk 1.2, which development has been closed, AFAIK. > > The attached patch "solves" it, but I'm not sure, wether the standard > > behaviour should be overridden. > > how hard would it be to make it a runtime option? something in dillorc? that > way you can have standard behavior and also the option to change its behavior > to satisfy people like me? Actually, it envolves reading Havoc Pennington's essay "Free software and good user interfaces" (http://ometer.com/free-software-ui.html) especially the section "The Question of Preferences", and considering, whether or not this configuration option should be added. Actually, I'd rather like it either having applied or not (not configurable), the others should apply the patch. (Adding the code is BTW rather simple, just look at how other options are handled in "prefs.c".) > how about this. let me know when the CVS tree stablizes and i'll write that > for you. It will probably still take some time, it is a bit more difficult than I thought. Sebastian

May 31, 2004

[Dillo-dev]Some remarks on the UI

by Sebastian Geerken

Hi, several remarks on the UI, which should be fixed IMO. 1. Bug meter: The bug meter button reacts on the "pressed" event, to show the window, but it should react on the "clicked" signal. Popping up a window after a "pressed" signal is usually only done for volatile windows (like menus, or overview windows, like in GIMP, which often vanish again, after releasing the mouse button). Reacting on "pressed" is always a bit problematic, also because the pointer grab initiated with this event can cause side-effects. Furthermore, it should not have a relief, compare to the "Hide Controls" button. 2. The menus behind the "Back" and "Forward" buttons: Consider the following scenario: (i) The user presses button 3 on the "Back" button, and the menu is shown. (ii) He keeps the button pressed, moves to one entry in the menu, and releases the button. Nothing happens. Currently, the menu items only react on "button_press", which is anyway wrong (see above). Furthermore, in this situation, the item should already react on the "release" event, either as described above, or in the way (i) click on menu, (ii) click on menu entry. The current behaviour is that much confusing, that a user may think that it does not work at all. (I did!) (The implementation would become a bit tricky, since button 2 will pop up the page in a new window. Perhaps, I'd even suggest to skip this feature, if a clean solution is not possible.) BTW, it is not very obvious, that there is a menu behind these two buttons. Perhaps there should be, in the icon, a small arrow directed downdwards, or so. 3. Attached is the incomplete code of a new widget, which changes the behaviour of GtkButton: (i) It reacts also on button 2 and 3, this would make multiple functions for one button possible. Actually, this feature should be reserved for very few situation (since it is simply confusing), namely the "Clear URL" button, which may also be used for visiting the URL in the selection buffer. (ii) It provides a function for attaching a menu in a better way, than we have currently, for the "Back" and "Forward" menus, and for the bug meter. Simply copy all files into one directory, call "make", and run "testprg". Look, what happens with different mouse buttons. Comments welcome. Sebastian

May 31, 2004

[Dillo-dev]page increment (was: very simple question, and many kudos!)

by Sebastian Geerken

On Sun, May 30, Jorge Arellano Cid wrote: > On Fri, 28 May 2004, Brian Hechinger wrote: > > so far, it's perfect for me. the only thing that i have a question about is > > PgUp and PgDn only moving half a page at a time. is there a way to get them > > to move a full page? > > Some time ago there was a patch, that i'd gladly apply, for > that. Maybe Sebastian has it. I'm not sure. Sebastian? Scrolling half a page is actually standard behaviour of Gtk, look e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or less responsible for this in our case, since our code uses GdkAdjustment::page_increment, which is set there. The attached patch "solves" it, but I'm not sure, wether the standard behaviour should be overridden. Sebastian PS: I'm currently working on huge changes in Dw, so committing patches to Dw shold currently avoided when possible.

May 31, 2004

[Dillo-dev]https (eg for posting to ps2 bulletin boards)

by robert w hall

Every time I read the playstation2-linux lists I realise how very useful dillo will be when it gets just a little further. How's the short/medium term future of https looking?(*) If an official plugin is in the offing then that's probably what we should all wait for. Otherwise, is the patch from 0.7 resurrectable?? Bob (*You need ssl to post to the ps2 bulletin board) -- robert w hall

May 30, 2004

Re: [Dillo-dev]very simple question, and many kudos!

by Brian Hechinger

On Sun, May 30, 2004 at 11:43:35AM -0400, Jorge Arellano Cid wrote: > > > so i got it. i have to say, i can't even put my surprise of how fast it was > > into words. i was floored. this is EXACTLY what i needed. > > Thanks for the good feedback! This information is important for us. hey, it's no problem, you guys certainly deserve it! i've been getting tired over the years of web browsers that have gotten so bloated that they have become completely unusable on slower older computers. i mean, come on, mozilla is _slow_ on my dual 200Mhz Octane with 1.5G ram, and that thing is a far cry from being a slow computer. > > so far, it's perfect for me. the only thing that i have a question about is > > PgUp and PgDn only moving half a page at a time. is there a way to get them > > to move a full page? > > Some time ago there was a patch, that i'd gladly apply, for > that. Maybe Sebastian has it. I'm not sure. Sebastian? if you could come up with that, that would be awesome. thanks!! > > thanks, and keep up the excellent work!! > We try. well keep trying!! i need frames!! ;) -brian -- "Performing a Google search on the fairly unique name you've chosen weeks ago for a piece of software you're writing, only to discover that the sole occurance of that name is as a pen-name for someone who spends his spare time writing X-rated PowerPuff Girls fan fiction is pretty-much a buzzkill." -- Jonathan Patschke --

May 30, 2004

Re: [Dillo-dev]help with start page

by Jorge Arellano Cid

On Fri, 28 May 2004, Turcios Manuel Pita wrote: > Hi i have some trouble with dillo that i want to fix. We have (at work) installed dillo on a coffenet application as the web browser by default to users to check their email under imap. Quite interesting. > So i need to change it te start page that it takes by default as www.dillo.org. > I had checked /etc/dillorc but it seems not to be there. May u help us to solve that?? There're two different things here: 1.- The start page (the one we call "splash" screen). 2.- The home page (accesable with the "Home" Icon). The home page is easily changed from dillorc. The splash page (the one that says "Welcome to to Dillo 0.8.1") can't be changed from dillorc yet. To me, it looks as though you want to change the splash page. If so, please write us back (it doesn't look as a bad idea adding the option to dillorc). In the meanwhile, you can override the splash page by passing dillo an URL from the command line: dillo http://myplace.org/ If you want this done automatically, make a shell script that aliases dillo. Cheers Jorge.-

May 30, 2004

Re: [Dillo-dev]very simple question, and many kudos!

by Jorge Arellano Cid

On Fri, 28 May 2004, Brian Hechinger wrote: > first off, i would like to say that i am completely impressed with dillo's > efficiency. i finally found myself to be in the position where i needed to > get X11 onto my Toshiba Tecra notebook so that i could use a web browser. > it's a 166Mhz with 32M ram, so i asked around what would be the best browser > for such a low resource machine, and was told firefox by a few. so i got a > copy of firefox. it was so slow, not only was it unusable, it made the rest > of my computer unusable. then someone mentioned dillo. > > so i got it. i have to say, i can't even put my surprise of how fast it was > into words. i was floored. this is EXACTLY what i needed. Thanks for the good feedback! This information is important for us. > so far, it's perfect for me. the only thing that i have a question about is > PgUp and PgDn only moving half a page at a time. is there a way to get them > to move a full page? Some time ago there was a patch, that i'd gladly apply, for that. Maybe Sebastian has it. I'm not sure. Sebastian? > thanks, and keep up the excellent work!! We try. Cheers Jorge.-

May 30, 2004

Re: [Dillo-dev]dillo as a debian package ..?

by Jorge Arellano Cid

On Tue, 25 May 2004, Willem van Engen wrote: > Hi all, > > ok, I made a new .deb for 0.8.1 and setup an apt repository on > http://willem.engen.nl/debian > please read debian install instructions there. I did only some very > basic tests and seems to work nicely. Please report if I missed > something. Thanks a lot Willem! I asked a couple of persons to try it, and added a link from the download page. If someone can help with the official package, it'd be very good too... Cheers Jorge.-

May 30, 2004

Re: [Dillo-dev]help with start page

by Livio Baldini Soares

Hi Turcios, Turcios Manuel Pita writes: > Hi i have some trouble with dillo that i want to fix. We have (at work) > installed dillo on a coffenet application as the web browser by default to > users to check their email under imap. > So i need to change it te start page that it takes by default as www.dillo.org. > I had checked /etc/dillorc but it seems not to be there. May u help us to solve > that?? I don't quite understand what you mean you "checked and it was not there". Do you mean the file or the "home" option? Anyways, you can copy the one that came with your tarball (or the one from http://www.dillo.org/dillorc) to /etc/dillorc, and see if that works. If it doesn't it probably means that dillo was configured (at compile time) to have a sysconfdir different than /etc (you can maybe try /usr/local/etc). Worst case, you have to tell all your users to copy the dillorc to $HOME/.dillo/dillorc BTW: I haven't found "dillorc" documented anywhere on the dillo sites or source documentation... but maybe I'm looking in the wrong place. hope this helps, -- Livio B. Soares

May 28, 2004

[Dillo-dev]help with start page

by Turcios Manuel Pita

Hi i have some trouble with dillo that i want to fix. We have (at work) installed dillo on a coffenet application as the web browser by default to users to check their email under imap. So i need to change it te start page that it takes by default as www.dillo.org. I had checked /etc/dillorc but it seems not to be there. May u help us to solve that?? Thankig u in advance Tech. Turcios Manuel Pita __________________________________________________ Correo Yahoo! - 6 MB, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.es

May 28, 2004

[Dillo-dev]very simple question, and many kudos!

by Brian Hechinger

first off, i would like to say that i am completely impressed with dillo's efficiency. i finally found myself to be in the position where i needed to get X11 onto my Toshiba Tecra notebook so that i could use a web browser. it's a 166Mhz with 32M ram, so i asked around what would be the best browser for such a low resource machine, and was told firefox by a few. so i got a copy of firefox. it was so slow, not only was it unusable, it made the rest of my computer unusable. then someone mentioned dillo. so i got it. i have to say, i can't even put my surprise of how fast it was into words. i was floored. this is EXACTLY what i needed. so far, it's perfect for me. the only thing that i have a question about is PgUp and PgDn only moving half a page at a time. is there a way to get them to move a full page? thanks, and keep up the excellent work!! -brian -- "Performing a Google search on the fairly unique name you've chosen weeks ago for a piece of software you're writing, only to discover that the sole occurance of that name is as a pen-name for someone who spends his spare time writing X-rated PowerPuff Girls fan fiction is pretty-much a buzzkill." -- Jonathan Patschke --

May 28, 2004

Re: [Dillo-dev]dillo as a debian package ..?

by Willem van Engen

Hi all, ok, I made a new .deb for 0.8.1 and setup an apt repository on http://willem.engen.nl/debian please read debian install instructions there. I did only some very basic tests and seems to work nicely. Please report if I missed something. Regards, - Willem On Tue, 25 May 2004 07:57:22 -0400 (CLT) "Jorge Arellano Cid" <jcid(a)dillo.org> wrote: > > Hi! > > It's been a long time since the debian package for Dillo is not > updated. Since 0.7.3 to be accurate. :-( > > I've contacted Phil and, surprisingly, the only reason for them > not being made is lack of time. > > Is here a Debian developer that can take the burden, or help > Phil, or at least provide us with an x86 .deb to link to from the > download page? > > It seems important because Debian lingering on 0.7.3 implicitly > passes the (wrong) message of the latter versions of dillo not > being worth an upgrade. > > > TIA > Jorge.- > > > ---------- Forwarded message ---------- > From: Jesper Olsen <__lazer __at phreaker__ net__> > To: jcid(a)dillo.org > Subject: dillo as a debian package ..? > > hello there .. > > Is there somewhere around where i can get dillo-0.8.1 as a .deb file?? > i can't find it, i've almost looked everywhere :s > > MaNN, thank you for a wonderful browser .. it runs top stable and > fast on my 166mhz .. well, it is a shame that i can't get the new > versions of the browser ! > > DILLO ROCKS!!!!! > > > - lazer > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

May 25, 2004

Re: [Dillo-dev]helper applications and their uses

by Jorge Arellano Cid

On Sat, 22 May 2004, Randy wrote: > Hello, > > First of all,let me say that i don't know a command-line from a chorus > line-my feeble knowlege of Linux consists mainly of downloading Apt and > Synaptic for my RH7.3 and FC1 distros,and handling it all from the GUI. > Just letting you know that your'e dealing with a novice here. : ) Thanks for the intro. > I like the concept behind Dillo,simple and fast. Beyond the concept --and as a novice user--, I'd like to know what do you like about dillo now? (provided you continued using it! :) For how long have you used it, and what advantage _you_ see over a full blown browser like mozilla. (In my experience, Dillo is more appreciatted by developers and power users. Mainly because they know how to get the maximum of it). In a nutshell: I'd like to know how is Dillo perceived from a novice user's point of view. > I understand that you > might be working on a version for frames later on,which would be even > better of course.My question though-without reliance on the usual > Mozilla plug-ins(which Galeon,Epiphany and Firefox also use) is there > anything I can download as a helper application? Would the full Java,for > example,interact at all with Dillo when browsing the Web? Would > Realplayer,or Gxine with Real plug-ins(i'm on Gnome,of course). Mozilla's plugins don't work with Dillo. Mozilla-based browsers (as Galeon, Firefox not sure about Epiphany), most probably will work with them). Dillo has its own (simple) scheme for plugins, and they come in the same tarball as the browser. For instance, bookmarks is a dillo plugin, downloads too and ftp. Even when there's a way to patch Dillo to run Java applets, I'd recommend other browser for Java, and definitively dillo doesn't do Javascript (Java and Javascript are different things). With regard to Realplayer or Gxine or PDF, or mpeg or audio or whatever processable datastream we can find in the web these days, it is not difficult to develop a dillo plugin that handles it to the matching viewer, but it's not currently provided with dillo, and probably you'll have to wait too much for the feature (lack of developers beaing the main cause). Try to get the best of the Dillo browser as it is now, be sure to always use the latest version, and please answer the questions above. I'm a developer! Cheers Jorge.-

May 25, 2004

[Dillo-dev]dillo as a debian package ..?

by Jorge Arellano Cid

Hi! It's been a long time since the debian package for Dillo is not updated. Since 0.7.3 to be accurate. :-( I've contacted Phil and, surprisingly, the only reason for them not being made is lack of time. Is here a Debian developer that can take the burden, or help Phil, or at least provide us with an x86 .deb to link to from the download page? It seems important because Debian lingering on 0.7.3 implicitly passes the (wrong) message of the latter versions of dillo not being worth an upgrade. TIA Jorge.- ---------- Forwarded message ---------- From: Jesper Olsen <__lazer __at phreaker__ net__> To: jcid(a)dillo.org Subject: dillo as a debian package ..? hello there .. Is there somewhere around where i can get dillo-0.8.1 as a .deb file?? i can't find it, i've almost looked everywhere :s MaNN, thank you for a wonderful browser .. it runs top stable and fast on my 166mhz .. well, it is a shame that i can't get the new versions of the browser ! DILLO ROCKS!!!!! - lazer

May 25, 2004

[Dillo-dev]Dillo RPM available for Yellow Dog Linux 3.0

by Kelson Vibber

In case anyone's interested, I posted an RPM for Yellow Dog Linux 3.0 over the weekend. The usual place: http://www.hyperborea.org/software/dillo/ -- Kelson Vibber www.hyperborea.org

May 24, 2004

[Dillo-dev]0.8.1 text centering error? (fwd)

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: 18 May 2004 04:15:11 PDT From: Gregg <dude(a)scorpiorising.ca> To: Dillo <dillo-dev(a)lists.auriga.wearlab.de> Subject: [Dillo-dev]0.8.1 text centering error? Hello, I have compiled and run Dillo 0.8.1 flawlessly on Debian woody. However, I notice the browser "centering text" that wasn't on 0.8.0 and earlier. Example: http://www.cknw.com - my daily news, now shows the headlines as centred. Is this supposed to be? Thanks, -- Gregg _______________________________________________ Dillo-dev mailing list Dillo-dev(a)lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

May 23, 2004