- Dillo-dev - lists.mailman3.com

[Dillo-dev]Dillo & linuxmail.org
by Lars Segerlund June 21, 2004

June 21, 2004

I just checked out the latest dillo and I can alsost get my linuxmail.org account to run in it. Does anybody have any idea about what might be the problem ? / Lars Segerlund.

2 2

[Dillo-dev]BUG#570
by Jorge Arellano Cid June 19, 2004

June 19, 2004

Hi Sebastian, Please give a look at BUG#570: 570 Impact: soft error At: run time Type: render bug Comments: Inconsistent render. First load or reload renders different than cached load (back/forward) HTReproduce: open dillo, nav to http://slskboard.savagenews.com/index.php (notice the first forum name i.e.) press back press forward (different cell width) WorkedBy: nobody Submitter: unknown it is very interesting and perhaps related to the rendering problem of our home page with dialups (resizing of alt-sized cells to actual image size). Cheers Jorge.-

1 0

[Dillo-dev]Problems with the activation of the URL entry
by Sebastian Geerken June 18, 2004

June 18, 2004

Hi! The current CVS version is supposed to visit the URL in the selection, when the user clicks with the middle mouse button on the "clear URL" button. However, I got it once working (strangely), but currently it does not work. I use Gtk+ version 1.2.10. The function Interface_entry_paste_selected first copies the selection into the entry (as you see from the comment, I did not really understand the code), and then calls gtk_widget_activate, which emits the activation signal of the widget, which is "activate" for GtkEntry, and normally emitted when the user presses the enter key within the entry. This signal is connected to the function a_Interface_entry_open_url. When a_Interface_entry_open_url is called in this case, gtk_editable_get_chars returns an empty string, it seems that the "real" copying of the selection in Interface_entry_paste_selected is somehow delayed. As workarounds, I see two possible solutions: 1. Also queueing our code in an idle function. The attached patch demonstrates this successfully, although it has to be cleaned up (in some cases, the active idle function has to be removed again). 2. Calling a_Interface_entry_open_url directly with the contents of the selection. (But how do I get the latter?) I'm not very familiar neither with selection in general (i.e. the protocols provided by ICCCM), nor with the mechanisms Gtk+ provides. If someone knows a better solution, please describe it (or send a patch). If not, I'd clean up and commit solution 1. Sebastian

2 3

[Dillo-dev]More on the UTF-8 issue
by sam+dillo＠chaosring.org June 16, 2004

June 16, 2004

First of all, I would like to thank Jorge for working on Dillo; it fills the need for there to be a lightweight *nix browser for older systems and times when one doesn't want to devote a lot of system resources just to access the world wide web. It is an excellent browser. When performing cross-browser verification, I discovered that Dillo 0.8.1 does not honor the following line in an HTML header: <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> Despite the presence of this line, Dillo assumed that the web page was encoded in Latin-1. Jorge, in a message with the subject "UTF-8", sent on June 3rd, wondered why someone would encode an English-language webpage with UTF-8. I can not speak for other webmasters, but the reason I personally encode my webpage in UTF-8 is because I do my web design on a Fedora Core 2 box, an OS that generally assumes that plain text files are encoded with Unicode instead of the iso-8859 mess. Also, Unicode gives one the flexibility to have Greek letters for Greek words, Cryllic letters for Russian words, and what not. Not to mention a number of attractive typographical symbols that Latin 1 does not have. Now, obviously, considering Dillo's target audience, it doesn't need full Unicode support. But it would be nice if it could handle basic UTF-8 encoded Latin-1 characters in web pages [1]. As an aside, I think Dillo currently has excellent CSS support (namely, none whatsoever). The thinking behing CSS is that a webpage should be perfectly readable on a browser with no CSS support; the content (if not the presentation) of a CSS webpage is perfectly accessible from a non-CSS browser. I come from the "CSS shouldn't be done at all, or should be done perfectly" camp. Considering the number of hacks web designers have come up to make CSS visible to this browser yet invisible to that browser [2], the last thing a webmaster wants is yet another buggy CSS implementation. - Sam [1] Some hacky code I once wrote, that reads UTF-8 from standard input, and outputs iso 8859-1: if(c<128) { printf("%c",c); } else { if(c < 0xe0) { /* two-byte sequence */ v = c & 0x1f; v <<= 6; c = getc(stdin); v = v + (c & 0x3f); printf("%c",v); } else { /* multi-byte sequence */ while(c & 0xc0 == 0x80 && !feof(stdin)) { c = getc(stdin); } } } (This code, FWIW, is public domain) It is probably better to simply use iconv. [2] http://centricle.com/ref/css/filters/ shows all of the common CSS hacks webmasters do these days.

3 2

[Dillo-dev]building 0.8.1 on slack4.0 (libc5)
by robert w hall June 14, 2004

June 14, 2004

I'm trying to compile dillo 0.8.1 to use on my old 486-based laptop (with slack 4.0, which is libc5-based). I've compiled glib + gtk 1.2.10 from source, but have no other libs like libjpeg, libpng etc. The binary starts to run then collapses in gdk error - error 11 in X-server (or similar message) Any advice? -- robert w hall

2 4

[Dillo-dev]Bug Meter suggestion
by Kyle Amon June 13, 2004

June 13, 2004

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.

2 2

Re: [Dillo-dev]Some remarks on the UI
by Jorge Arellano Cid June 10, 2004

June 10, 2004

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

2 2

[Dillo-dev]fixed font failed in dillo on NetBSD
by tman June 10, 2004

June 10, 2004

I updated packages from source dated June 7 including (amoung others): fontconfig-2.2.95 perl-5.8.4 glib-1.2.10nb6 gtk+-1.2.10nb7 glib2-2.4.2 gtk2+-2.4.2 atk-1.6.1 pango-1.4.0 x11-links-0.23 dillo-0.8.1 When I ran dillo after upgrading, no fonts displayed in the browser. Before updating, fonts displayed. In dillorc I changed vw_fontname from default heletica to lucida, and dillo now displays variable width font. I changed fw_fontname from default courier to fixed, and then lucidatypewriter, but cannot get fixed fonts to display. What busted?

1 0

[Dillo-dev]Dillo: Bug#568
by Jorge Arellano Cid June 9, 2004

June 9, 2004

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

4 3

[Dillo-dev]patch for bug 211
by Diego Sáenz June 9, 2004

June 9, 2004

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

2 3