June 2004 - Dillo-dev - lists.mailman3.com

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