Re: [Dillo-dev]next encodings patch From: Grigory Bakunov - 2001-09-28 01:47 Date |28 Sep 2001 04:28:56 +0400 From |Michael Govorun Hello! MG> Grigory Bakunov writes: >> REALY i look through dw_style.c code and doesn't see nothing difficult. >> But you need to change ALL gdk_font_load calls to gdk_fontset_load. It's all. >> So sed 's/gdk_font_load/gdk_fontset_load/g' and enjoy with dillo and your lovely charsets -) MG> Thanks. it works. MG> But there is another one problem - POST encodings. If server sends to you MG> page in (for example) cp1251 it expects POST data also in MG> cp1251. Now Dillo sends text as is. I work on it. It's not more difficult than recoding html -) ___________________________________________________________________ Truly yours, Grigory Bakunov ASPLinux Support Team http://www.asplinux.ru Re: [Dillo-dev]next encodings patch From: Michael Govorun - 2001-09-28 00:29 Grigory Bakunov writes: > REALY i look through dw_style.c code and doesn't see nothing difficult. > But you need to change ALL gdk_font_load calls to gdk_fontset_load. It's all. > So sed 's/gdk_font_load/gdk_fontset_load/g' and enjoy with dillo and your lovely charsets -) Thanks. it works. But there is another one problem - POST encodings. If server sends to you page in (for example) cp1251 it expects POST data also in cp1251. Now Dillo sends text as is. -- Michael Govorun Re: [Dillo-dev]next encodings patch From: Michael Govorun - 2001-09-27 17:21 Grigory Bakunov writes: > MG> Hmm. Not working for me :( > MG> It recodes, but not properly. > What type of problems you have ? Oh. I think my problem is: Jorge Arellano Cid writes: >Hi there! > Sometime ago there was a thread on fonts/character enocoding > problems. Current CVS has gtk_set_locale and Karsten's patch for > font loading. >> The problem is that search sequence for fonts is arbitrary, and ISO10646 >> fonts can appear before ISO8859 fonts. Gtk doesn't handle ISO10646 >> fonts properly, hence the resolution problems. > The fix I've applied is to hardcode the font encoding into the font > search string in dw_style.c. -- Michael Govorun Re: [Dillo-dev]next encodings patch From: Grigory Bakunov - 2001-09-27 15:46 Date |27 Sep 2001 12:47:58 +0400 From |Michael Govorun Hello! MG> Hello! MG> Grigory Bakunov writes: >> Hello. >> I'm new in this list so don't kick me strongly. >> I make a patch for force encodings selection. >> I drop it here MG> Hmm. Not working for me :( MG> It recodes, but not properly. MG> another thing: MG> What you think about configurable "Accept-Charset" http-header in MG> Http_query() function in IO/html.c. What type of problems you have ? I work on accept-charset now -) MG> -- MG> Michael Govorun ___________________________________________________________________ Truly yours, Grigory Bakunov ASPLinux Support Team http://www.asplinux.ru [Dillo-dev]Re: Dillo Basic auth patch From: Johannes Hofmann - 2001-09-27 15:35 Hi, > To avoid confusion about who said what, please stick the right name > to the quote. :) Sorry for that. The confusion is my fault. I forwarded the small diskussion between Tor-Åke Franssons and me to the list. To avoid his email to be shown in the archive I removed the corresponding lines in the subject and the mail-bodies. I only recognized later, that email addresses in the mail-bodies are protected by the archive automatically. Regards, Johannes Hofmann. [Dillo-dev] Re: Dillo Basic auth patch From: Sam J. - 2001-09-27 10:40 On Thursday 27 September 2001 12:31, Tor-=C5ke Fransson wrote: > Quoting Sam J. Engstrom: > >On Monday 24 September 2001 19:15, Johannes Hofmann wrote: > >> Seriously, i intend to use dillo in my ipaq, and using handwriting > >> recognition with '****' feedback is kind of hard. Also, i was not su= re > >> my base64 encoding routine(!) was solid, so i wanted to [...] > > Johannes Hofmann did not write that. I did. > > To avoid confusion about who said what, please stick the right name to = the > quote. :) That's odd, the automatic quoting seemed correct because the From-header=20 in the mail says it's from Johannes Hofmann, even though your name is in = the=20 bottom of the message, but I apparently cut it out before noticing. So I=20 guess the original mail was forwarded to the list but I don't see any men= tion=20 of that. > ... or just make a workaround, trap "entry_changed" and change the entr= y > contents, but that requires storing the password in some other place th= an > in the widget. Won't the passwords need to be stored somewhere anyway, to remember passw= ords=20 to several sites during a session as other browsers do? It also would be = nice=20 if you could clear them without restarting the browser. --=20 Sam J. Engstrom Tel. +358 400 462442 mail@sa... Managing Director Nemesol http://nemesol.fi [Dillo-dev]Re: Dillo Basic auth patch From: - 2001-09-27 09:31 Quoting Sam J. Engstrom: >On Monday 24 September 2001 19:15, Johannes Hofmann wrote: >> Seriously, i intend to use dillo in my ipaq, and using handwriting >> recognition with '****' feedback is kind of hard. Also, i was not sure >> my base64 encoding routine(!) was solid, so i wanted to [...] Johannes Hofmann did not write that. I did. To avoid confusion about who said what, please stick the right name to the quote. :) > Maybe the password field could briefly show the newest letter and then > change it to an asterisk, like I've seen in some Nokia phones. So the > letter is > visible long enough to see what you've typed, but the whole password is > never shown. I use dillo on the ipaq all the time, and agree that seeing > what you're writing helps a lot. [...] That is a very good idea! But... the correct place to implement that feature is in the gtk library, make the 'visible' attribute an enum instead of gboolean, and have the function gtk_entry_draw_text() in gtkentry.c do the right thing. I.e we need to convince a lot of people this is a good idea, unless we want provide our own libgtk with dillo, or subclass our own gtk_entry and stuff that into dillo. Can't replace just the gtk_entry_draw_text() function externally either, it's hardwired into the gtkentry.c code in several places. ... or just make a workaround, trap "entry_changed" and change the entry contents, but that requires storing the password in some other place than in the widget. Regards, Tor-Åke Re: [Dillo-dev]next encodings patch From: Michael Govorun - 2001-09-27 08:48 Hello! Grigory Bakunov writes: > Hello. > I'm new in this list so don't kick me strongly. > I make a patch for force encodings selection. > I drop it here Hmm. Not working for me :( It recodes, but not properly. another thing: What you think about configurable "Accept-Charset" http-header in Http_query() function in IO/html.c. -- Michael Govorun Re: [Dillo-dev]Re: Dillo Basic auth patch From: Sam J. - 2001-09-26 23:33 On Monday 24 September 2001 19:15, Johannes Hofmann wrote: > Seriously, i intend to use dillo in my ipaq, and using handwriting > recognition with '****' feedback is kind of hard. Also, i was not sure my > base64 encoding routine(!) was solid, so i wanted to see that i really > gave it the right password. I trust that will be changed, should my patch > go into CVS. Maybe the password field could briefly show the newest letter and then change it to an asterisk, like I've seen in some Nokia phones. So the letter is visible long enough to see what you've typed, but the whole password is never shown. I use dillo on the ipaq all the time, and agree that seeing what you're writing helps a lot. Sorry, no patch for it, just the idea. I haven't even had time to test the actual auth patch yet. -- Sam J. Engstrom Tel. +358 400 462442 mail@sa... Managing Director Nemesol http://nemesol.fi [Dillo-dev]next encodings patch From: Grigory Bakunov - 2001-09-26 22:27 Hello. I'm new in this list so don't kick me strongly. I make a patch for force encodings selection. I drop it here http://lambda.asplinux.udm.net/pub/dillo/dillo.encodings.patch It's based on japanise encodings patch but can help all users who use nonlatin1 charsets (especialy this patch help for all cyrillic readers with our charsets hell). Patch use iconv and work with 'encodings' file that i drop into ~/.dillo/ (like bookmarks.html). File contain "Charset name" "iconv name" pairs in form AscII Cyrillic KOI8-R Cyrillic CP1251 Cyrillic IBM866 Unicode etc... As you can see this patch help me to view unicode and other charsets page. Patch aplayed on current (Thu Sep 27) CVS. To check it drop 'encodings' file to your ~/.dillo/ Name of iconv charsets you can get from iconv --list (for glibc iconv) ___________________________________________________________________ Truly yours, Grigory Bakunov ASPLinux Support Team http://www.asplinux.ru Re: [Dillo-dev]Fwd: dillo patch for Fugly Fonts From: Jorge Arellano Cid - 2001-09-26 20:33 Hi there! Sometime ago there was a thread on fonts/character enocoding problems. Current CVS has gtk_set_locale and Karsten's patch for font loading. > The problem is that search sequence for fonts is arbitrary, and ISO10646 > fonts can appear before ISO8859 fonts. Gtk doesn't handle ISO10646 > fonts properly, hence the resolution problems. > > The fix I've applied is to hardcode the font encoding into the font > search string in dw_style.c. As I've explained before, dillo works in ISO8859-1, so this patch is OK by now (further info in [Project Notes]). To those of you that have had problems before, please test current CVS and report back whether it solves the problem or not. Ah, some of you may require: `LC_ALL=POSIX ./dillo` Good luck! Jorge.- [Dillo-dev]Dillo for the blind and visually impaired. From: Simon Dobrisek - 2001-09-26 09:33 Dear colleagues, I am a teaching assistant and part of my research work at our university is to develop a simple but usable web browser for the blind and visually impaired people. For some time we have been involved in a non-profit research project wher= e we developed a voice-driven text-to-speech system (HOMER II) for blind or visually impaired persons for reading Slovenian texts ( my country ;) ). Later on we got an idea to set a web portal entirely dedicated to such disabled persons in Slovenia and to develop a HOMER III system which includes an html parser. Additionally, we decided to enable use of mouse pointer when browsing through the available text at the portal (some useful info, daily newspapers, selected novels ... all preformated into simple html pages ... the portal does not exist yet :( ... but an interne= t source of nonstructed ASCII Slovenian texts does!) And then I "discovered" the dillo. We have already done some job and our extension of the dillo has a screen reading capabilities (with the Slovenian text-to-speech and a lot of beep sounds ;) ... it works only when pointer is in the "dw_page"). The working name of the system is "ihomer". I have to say that I am a rookie in GTK programming and the dillo project= . I hope I didn't pollute the code with too much unstable crap but it seems stable (as much as dillo is stable). Our extension of the source code wil= l be publicly available (without the Slovenian TTS but with the instruction= s how to integrate other language TTS ... actually we have version with the "dummy synthesis - delayed print" to the console window). And now the main point! Currently, I am stucked with a problem of how to hook on the low level signals of the GTK menus and buttons in the dillo. I would need to "intercept" the position of the pointer in the menu (better said, I need the menu or button label text beneath the pointer to send it to the TTS). TTS works in a separated thread with a time out function. This means that you can't stuff the TTS with some fast browsing. You need to stay in a position for some time to hear anything from the TTS. This feature of our TTS seem to be stable when browsing through the dw_page. (I hooked TTS on the motion_notify_event of the dw_page) Do you have any hint, instructions? Thanx! as.dr. Simon Dobri=B9ek simond@lu... [Dillo-dev]Updated auth patch available From: - 2001-09-25 23:16 An updated basic auth patch is available at: http://www.lysator.liu.se/~torkel/computer/ipaq/dillo_auth0925.diff.gz I have merged in some changes from Pekka Lampila (handle http://user:pass@fo.../) and Johannes Hofmann (don't show password on screen). I also added some bits of my own and made the patch clean against todays CVS. Enjoy. //Tor-Åke [Dillo-dev]International language support for dillo From: Hector Garcia Alvarez - 2001-09-25 22:40 Hi all I would like to add international language support into dillo. Of course those people using it on Palm like machine could compile it without this support to keep it smaller. Is anybody working on this already? How do I send the patch and where? Regards, H=E9ctor [Dillo-dev]Re: Bookmark System From: Jorge Arellano Cid - 2001-09-24 16:18 Alex, > Hey, i'd like to start working on the bookmark system, i already have > added seperators and an "Add Seperator" option to the menubar. Is anyone > else working on the bookmark system? Yes, I read your posts. This issue was discussed on the list a long time ago; current bookmarks code far from good, we know, and the main reason for not being working it out, is the idea of making our bookmarks implementation based on the plugin interface. Since the plugin implementation had been procrastinated to favor higher priorities, so had the bookmarks code. As we're getting closer to resume our work with the plugin interface, you'd better wait until it's done and gauge its potential. For instance, now that tables are working good, a table based display with two main columns, one for bookmark category (left) and the other for their listings, seems quite adequate. Let's add a top panel for delete, move, create category, export as HTML ... functions, plus the necessary #anchor bindings from the left panel to the main one, and we have an interesting proposal... And as plugins are external programs, any not so common addition a user may want can be added to a specific custom plugin without requiring it to make into dillo's source base. The whole concept of dillo (simple) plugins is very powerful, but yet to be tested. Eric and I had put a lot of work into it, so I keep looking forward for the day it begins to work as planned. A simpler approach has been tested to work OK (old plugin scheme), and it supported FTP quite nicely. Cheers Jorge.- [Dillo-dev]Re: Dillo Basic auth patch From: Johannes Hofmann - 2001-09-24 16:15 On Sat, 22 Sep 2001, Johannes Hofmann wrote: > Hm, so the right way to go would be protocol+hostname+port+realm... Ideally, yes. But you have no knowledge of what realm it is until you have received the reply header. Using the directory name you can however, make smart assumptions on what realm it is in, for example: if you enter a site at http://foo.bar.com/beer and it is in a certain realm, http://foo.bar.com/beer/heineken is probably in the same realm, while http://foo.bar.com/wine does not have to be. However, if you enter the site at http://foo.bar.com/ and authenticate there, beer and wine are assumed to be in the same realm with my method. I.e I use the "surfing pattern", to make guesses on what realm it is. I know it is not ideal. Should beer and wine be in the same realm, and you enter at beer, and then go to wine, you would have to enter a password even though you should not have to. > So I think best way to go would be your scheme, but in case of > authentication failure on a host we already have auth-info for, we > could look in the realm-list, if we already have auth-info for that > realm. If so, we could send it without bothering the user. Yes! That is a good idea. I'll think about how to implement that > There's just one thing I'm thinking about. > Once we have a ssl-connection with certificate-based server > authentication, we certainly don't want to send auth-info based on > protocol+hostname+port only, without checking for dns-spoofing. > But I do not know enough about how ssl-connections are handled. Are > they kept alive, so that authentication is needed only once? No, they are not necessarily kept alive. At least one site i know of (my bank) asks for authentication certificate over and over again while loading a page, which indicates it is not using keep-alive. I have not really looked into implementing certificate authentication, but i think it should be handled like this: 1. client makes request 2. server asks for client authentication certificate, sends server certificate 3. client looks at server certificate and compare it with its stored certificate for this server 4a. if 3. results in a match, client sends client certificate 4b. if the certificates does not match, warn the user about spoofing 4c. if we have no certificate for this server, notify the user, store the server certificate, and send client certificate. I believe this is how Netscape does it. I do not know how certificates are passed back and forth, and all of this seems too complicated and tideous for me to find time to implement it anytime soon, but please go ahead. :) Regards, Tor-Åke Fransson PS If you think we should let the other dillo people in on the discussion, feel free to forward this mail and mails preceeding it to dillo-dev@li... DS [Dillo-dev]Re: Dillo Basic auth patch From: Johannes Hofmann - 2001-09-24 16:14 On Fri, Sep 21, 2001 at 11:48:14PM +0200, Tor-Åke Fransson wrote: > > On Fri, 21 Sep 2001, Johannes Hofmann wrote: > > > I just have a small addition to the auth patch, to hide passwords from > > too curious people > > I was wondering how long it would take for someone to object to that ;) > > Seriously, i intend to use dillo in my ipaq, and using handwriting > recognition with '****' feedback is kind of hard. Also, i was not sure my > base64 encoding routine(!) was solid, so i wanted to see that i really > gave it the right password. I trust that will be changed, should my patch > go into CVS. Yeah, I already thought you left it in cleartext for debugging... > > > and a small modification to the auth data lookup. > > It looks up auth data based on the hostname, protocol, and port > > instead of the url prefix that was used before. > > Since different subdirectories on same host can be different realms, you > need the path also, ergo: > > protocol+hostname+port+path > > http://hostname:port/path, see? ;) > > > I think one also has to look it up based on the auth-realm, but I did > > not see how to implement that at the moment. > > You could do it by realm, but the server will only tell you the realm > after you have done a request, which in effect doubles the number of > requests! I also had that approach at first, but i abandoned it, since > dillo does not handle keep-alive connections. > > Even though it is not the 'right' thing to do, i think we can safely > assume all files in a directory are protected in the same realm. At least > it it very common to configure web servers that way. > > Using _just_ the realm is not good either, because a realm is > not guaranteed to be unique. I just have to name my realm the same as > yours, and trick your users to come and surf on my site > to steal passwords. You would need protocol+host+port+path+realm. Easy way > out is to skip the realm alltogether, hard way is to implement keep-alive, > to not double the number of connections. > > IMHO, leaking a password to the wrong realm is not that dangerous, unless > the server administrator lets users themselves change logging > configuration to steal the 'Authorization:' header line. Leaking it to the > wrong server is _much_ worse. > > In conclusion, it is all a tradoff between user convenience, speed and > password security. I aimed for "very convenient", "fast" and "pretty > safe". > Hm, so the right way to go would be protocol+hostname+port+realm... I thought leaking the password to the right server, but a wrong realm would be acceptable. Therefore, I you choose auth-info based on protocol+hostname+port and try if it works out. If the realm is wrong, I have to enter a new password. I see that this allows only one realm per server at a time :-( So I think best way to go would be your scheme, but in case of authentication failure on a host we already have auth-info for, we could look in the realm-list, if we already have auth-info for that realm. If so, we could send it without bothering the user. There's just one thing I'm thinking about. Once we have a ssl-connection with certificate-based server authentication, we certainly don't want to send auth-info based on protocol+hostname+port only, without checking for dns-spoofing. But I do not know enough about how ssl-connections are handled. Are they kept alive, so that authentication is needed only once? Regards, Johannes Hofmann [Dillo-dev]Re: Dillo Basic auth patch From: Johannes Hofmann - 2001-09-24 16:14 On Fri, 21 Sep 2001, Johannes Hofmann wrote: > I just have a small addition to the auth patch, to hide passwords from > too curious people I was wondering how long it would take for someone to object to that ;) Seriously, i intend to use dillo in my ipaq, and using handwriting recognition with '****' feedback is kind of hard. Also, i was not sure my base64 encoding routine(!) was solid, so i wanted to see that i really gave it the right password. I trust that will be changed, should my patch go into CVS. > and a small modification to the auth data lookup. > It looks up auth data based on the hostname, protocol, and port > instead of the url prefix that was used before. Since different subdirectories on same host can be different realms, you need the path also, ergo: protocol+hostname+port+path http://hostname:port/path, see? ;) > I think one also has to look it up based on the auth-realm, but I did > not see how to implement that at the moment. You could do it by realm, but the server will only tell you the realm after you have done a request, which in effect doubles the number of requests! I also had that approach at first, but i abandoned it, since dillo does not handle keep-alive connections. Even though it is not the 'right' thing to do, i think we can safely assume all files in a directory are protected in the same realm. At least it it very common to configure web servers that way. Using _just_ the realm is not good either, because a realm is not guaranteed to be unique. I just have to name my realm the same as yours, and trick your users to come and surf on my site to steal passwords. You would need protocol+host+port+path+realm. Easy way out is to skip the realm alltogether, hard way is to implement keep-alive, to not double the number of connections. IMHO, leaking a password to the wrong realm is not that dangerous, unless the server administrator lets users themselves change logging configuration to steal the 'Authorization:' header line. Leaking it to the wrong server is _much_ worse. In conclusion, it is all a tradoff between user convenience, speed and password security. I aimed for "very convenient", "fast" and "pretty safe". Best regards, Tor-Åke > *** interface.c.orig Fri Sep 21 18:10:18 2001 > --- interface.c Fri Sep 21 18:08:34 2001 > *************** > *** 1047,1052 **** > --- 1047,1053 ---- > gtk_box_pack_start(GTK_BOX(box1),*passwd_dialog_uentry, FALSE, > FALSE, 0); > gtk_widget_show(*passwd_dialog_uentry); > *passwd_dialog_pentry=gtk_entry_new(); > + gtk_entry_set_visibility((GtkEntry*) *passwd_dialog_pentry, FALSE); > gtk_box_pack_start(GTK_BOX(box1),*passwd_dialog_pentry, FALSE, > FALSE, 0); > gtk_widget_show(*passwd_dialog_pentry); > /* gtk_widget_show(frame); */ > > > > > *** auth.c.orig Fri Sep 21 18:14:58 2001 > --- auth.c Fri Sep 21 18:33:34 2001 > *************** > *** 43,73 **** > > GString *Auth_byurl(DilloUrl *n) > { > ! gchar *offset; > ! int i,longest=-1,len=0,longlen=0; > ! gchar *ptr; > > if (n == NULL) > return NULL; > ! > for (i=0;i { > ! /* is my compiler broken, why do i need this? */ > ! ptr=((DilloUrl *) realms[i].base_url)->url_string->str; > ! if (NULL == (offset = strrchr(ptr,'/'))) > ! offset=ptr+strlen(ptr); > ! if (strncmp(n->url_string->str,ptr,(char *) offset - (char *) ptr) == 0) > { > ! len=(gchar *) offset - (gchar *) ptr; > ! if (longlen <= len) > ! { > ! longlen=len; > ! longest=i; > ! } > } > } > - if (-1 != longest) > - return realms[longest].auth; > > return NULL; > } > --- 43,62 ---- > > GString *Auth_byurl(DilloUrl *n) > { > ! int i; > > if (n == NULL) > return NULL; > ! > for (i=0;i { > ! if (strcmp(n->hostname, realms[i].base_url->hostname) == 0 && > ! strcmp(n->protocol, realms[i].base_url->protocol) == 0 && > ! n->port == realms[i].base_url->port) > { > ! return realms[i].auth; > } > } > > return NULL; > } > > > [Dillo-dev][Johannes.Hofmann@gmx.de: Dillo Basic auth patch] From: Johannes Hofmann - 2001-09-24 16:13 Hi, first of all I want to thank you for your cool dillo patches (auth and https). I just have a small addition to the auth patch, to hide passwords from too curious people and a small modification to the auth data lookup. It looks up auth data based on the hostname, protocol, and port instead of the url prefix that was used before. I think one also has to look it up based on the auth-realm, but I did not see how to implement that at the moment. cheers, Johannes Hofmann *** interface.c.orig Fri Sep 21 18:10:18 2001 --- interface.c Fri Sep 21 18:08:34 2001 *************** *** 1047,1052 **** --- 1047,1053 ---- gtk_box_pack_start(GTK_BOX(box1),*passwd_dialog_uentry, FALSE, FALSE, 0); gtk_widget_show(*passwd_dialog_uentry); *passwd_dialog_pentry=gtk_entry_new(); + gtk_entry_set_visibility((GtkEntry*) *passwd_dialog_pentry, FALSE); gtk_box_pack_start(GTK_BOX(box1),*passwd_dialog_pentry, FALSE, FALSE, 0); gtk_widget_show(*passwd_dialog_pentry); /* gtk_widget_show(frame); */ *** auth.c.orig Fri Sep 21 18:14:58 2001 --- auth.c Fri Sep 21 18:33:34 2001 *************** *** 43,73 **** GString *Auth_byurl(DilloUrl *n) { ! gchar *offset; ! int i,longest=-1,len=0,longlen=0; ! gchar *ptr; if (n == NULL) return NULL; ! for (i=0;iurl_string->str; ! if (NULL == (offset = strrchr(ptr,'/'))) ! offset=ptr+strlen(ptr); ! if (strncmp(n->url_string->str,ptr,(char *) offset - (char *) ptr) == 0) { ! len=(gchar *) offset - (gchar *) ptr; ! if (longlen <= len) ! { ! longlen=len; ! longest=i; ! } } } - if (-1 != longest) - return realms[longest].auth; return NULL; } --- 43,62 ---- GString *Auth_byurl(DilloUrl *n) { ! int i; if (n == NULL) return NULL; ! for (i=0;ihostname, realms[i].base_url->hostname) == 0 && ! strcmp(n->protocol, realms[i].base_url->protocol) == 0 && ! n->port == realms[i].base_url->port) { ! return realms[i].auth; } } return NULL; } Re: [Dillo-dev]installation From: Matthieu Camus - 2001-09-24 09:24 Hi, Have you installed that package ? libjpeg62-devel-6b-19mdk Regards, Matthieu En r=E9ponse =E0 darren : > I found the link to dillo on the xfce website. Since I have been so > happy=20 > with xfce, I figure anything they recommend must be worth a look. But, > I'm=20 > having trouble installing it. =20 >=20 > As a side note, I joined this list in an effort to resolve my > installation=20 > problem. But, I didn't realize this was the development list until > after I=20 > had subscribed. The way to subscribe to the user's list and the way to >=20 > unsubscribe to the dev list was not obvious (I didn't see it, anyway). >=20 > So, pardon an installation question. =20 >=20 > I've tried compiling with the following options: >=20 > ./configure --with-jpeg-lib=3D/usr/lib --with-jpeg- > inc=3D/usr/lib/qt2/include >=20 >=20 > But, I'm still getting the following errors when I compile: >=20 > checking for jpeg_destroy_decompress in -ljpeg... no > configure: WARNING: *** JPEG support will not be included *** > no > configure: WARNING: *** JPEG support will not be included *** >=20 >=20 > Thanks for any help you can give, > Darren >=20 > BTW, this is on Mandrake 8.0. >=20 > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@li... > https://lists.so....net/lists/listinfo/dillo-dev >=20 Matthieu matthieu.camus@un... [Dillo-dev]installation From: darren - 2001-09-23 20:29 I found the link to dillo on the xfce website. Since I have been so happy with xfce, I figure anything they recommend must be worth a look. But, I'm having trouble installing it. As a side note, I joined this list in an effort to resolve my installation problem. But, I didn't realize this was the development list until after I had subscribed. The way to subscribe to the user's list and the way to unsubscribe to the dev list was not obvious (I didn't see it, anyway). So, pardon an installation question. I've tried compiling with the following options: ./configure --with-jpeg-lib=/usr/lib --with-jpeg- inc=/usr/lib/qt2/include But, I'm still getting the following errors when I compile: checking for jpeg_destroy_decompress in -ljpeg... no configure: WARNING: *** JPEG support will not be included *** no configure: WARNING: *** JPEG support will not be included *** Thanks for any help you can give, Darren BTW, this is on Mandrake 8.0. Re: [Dillo-dev]Pending tasks From: Viksell - 2001-09-23 10:38 Jorge Arellano Cid wrote: > ----------------- > Attribute parsing > ----------------- >=20 > As I posted before (Subject: "Attribute parsing"), this is a > high priority task that's pending. I received emails from Bruno > and J=F6rgen stating that they were willing to work on it, but not > knowing exactly were to start. My current schedule contemplates > working on this, the networking part of plugins, https and auth. > So If I start with the latter I'll have little time to help you > both, so J=F6rgen: if you feel confident enough to work on > attribute parsing, starting from my previous post, please let me > know so I can focus on networking; if not, let me know also so I > can start here. Sure, I'll do it. As I understand, it is just Html_get_attr that needs to be changed to support dynamic lengths and then move parsing of entities in there. Or are there any other "deeper" issues? > ------------------------ > https, cookies and auth. > ------------------------ >=20 > There were three issues to this: >=20 > 1) Stability (almost achieved) > 2) The specific implementation layer and network support > for them. > 3) https pages usually require working cookies. >=20 > As Tor-Ake and J=F6rgen have advanced with 2 and 3, I'll need to > know what this schemes require from the networking layers (for > instance, cookies require sending back stored cookies). >=20 > If you guys work together, and specify what you require from > the networking layers, and keep on improving the specific > implementation, it will come a time when I'll be free to > implement the underlaying support and hopefully then, it'll > become a matter of merging. I'll make a list of the required changes for cookies and send it to=20 the list some time. Kind of basic stuff except for some oddities with different cookie versions... > Note that cookies should provide dillorc options for: >=20 > - rejecting all cookies > - accepting only if the RootUrl and server match. > - accepting all Implemented with a separate file where you can set actions for a specific domain or for all domains. J=F6rgen [Dillo-dev]Pending tasks From: Jorge Arellano Cid - 2001-09-23 09:38 Hi everyone! Now that 0.6.1 has achieved a significant stability gain, we can focus on several other tasks that were waiting in the priorities queue. Note that the stabilization is not completed, but advanced enough to let other tasks to be started. ----------------- Attribute parsing ----------------- As I posted before (Subject: "Attribute parsing"), this is a high priority task that's pending. I received emails from Bruno and J=F6rgen stating that they were willing to work on it, but not knowing exactly were to start. My current schedule contemplates working on this, the networking part of plugins, https and auth. So If I start with the latter I'll have little time to help you both, so J=F6rgen: if you feel confident enough to work on attribute parsing, starting from my previous post, please let me know so I can focus on networking; if not, let me know also so I can start here. Note that there're other interesting tasks in this post that if you feel more comfortable with, can be as helpful to work on. -------------------------------------- Bug 216 (answers without content/type) -------------------------------------- Yes, I also had this problem with ebay (made a little hack, and won my bid!). Since that moment the idea of handling this case the rigth way is present. Note that the problem arises from a http answer lacking the content/type info; the RFC says it SHOULD be present, so it's not an error :( The solution is simple, do you remember magic numbers and the 'file' command? Well, that's the way to go. I don't mean calling 'file' and parsing its output, but to examine the magic numbers file (and its format) for the small set of MIME types dillo supports: image/{png, jpeg, gif} text/{plain, html} and afterward, to create a custom function that returns the MIME type of a file, by examining a few bytes from the start of it. Ex: gchar *a_Mime_get_content_type(const gchar *FewBytesString); After having this function, it's just a matter of binding it to header parsing. -------------------- Dicache memory usage -------------------- The cache system (cache and dicache) uses a lot of memory for images, because it stores the original format and the RGB decompressed one. Flushing the dicache is not easy because image widgets use the dicache buffers directly. The right solution is to implement a memory usage threshold on the dicache, but that would require a significative effort... As a workaround, there's a posibility of binding the 'about:splash' method (because it doesn't use images) to a dicache flushing function. i.e. whenever the splash screen is requested, the handling method asserts there's only a single browser window open and flushes the dicache (after displaying the splash). This is very far from a clean solution, but may serve those of you that feel in a dire need of it. ------- Plugins ------- One of the most procrastinated topics in dillo :( After attribute parsing is done, I'll be choosing between plugins and the networking part of https, cookies and auth. ------------------------ https, cookies and auth. ------------------------ There were three issues to this: 1) Stability (almost achieved) 2) The specific implementation layer and network support for them. 3) https pages usually require working cookies. As Tor-Ake and J=F6rgen have advanced with 2 and 3, I'll need to know what this schemes require from the networking layers (for instance, cookies require sending back stored cookies). If you guys work together, and specify what you require from the networking layers, and keep on improving the specific implementation, it will come a time when I'll be free to implement the underlaying support and hopefully then, it'll become a matter of merging. Note that cookies should provide dillorc options for: - rejecting all cookies - accepting only if the RootUrl and server match. - accepting all - [confirm] -- this must be very well thought, for not annoying the user. ----------------- Frames workaround ----------------- Before the final implementation of frames, a workaround (as dicussed on the list) would be a nice addition. I'll be waiting until Livio finishes testing and polishing the current prototype. ------- History ------- We are working with Eric on it. Expect a full creative solution to be there sometime :) I'm crossing fingers. ----------------------- BUG 205 (visited links) ----------------------- This is not a bug, but a feature! In dillo, visited link sematic is "cached". (it has proven useful) Note: 205 will be removed soon from BugTrack. ---------------- nowrap and width ---------------- The workaround for this construct was removed in concordance with dillo's html parsing policy ([Project Notes]). Also note that the HTML 4.01 spec says WIDTH is a "recommended" cell width (hints in dillo's implementation), and NOWRAP "disables automatic text wrapping for this cell", and it adds "NOTE: if used carelessly, this attribute may result in excessively wide cells". So current implementation is compliant with both. Regards Jorge.- Re: [Dillo-dev]word wrapping / page width From: Ulrich Schwarz - 2001-09-21 10:32 On Fri, Aug 31, 2001 at 03:39:41PM +0200, Sebastian Geerken wrote: >>> I thought of a workaround, which ignores the NOWRAP in this >>> case, in Html_tag_open_table_cell: > done Hm, the recent CVS version of dillo reverts to the old state before your patch, where NOWRAP is applied in conjunction with an existing WIDTH attribute. So long. Ulrich [Dillo-dev]Patch to make capitalisation consistent in dillo interface From: Adam Sampson - 2001-09-21 02:32 In dillo-0.6.1, some parts of the interface capitalise all words ("Find Text"), some capitalise some ("Open Link in New Window"), and some only capitalise the first ("Find text in page"). Also, the context menus have extra header items, which look odd and don't add significantly to usability (at least, when I'm using the menus I care about what I can do, not why I can do it!). This patch makes all the phrases I could find only capitalise the first word (because that's what Links does, and I happen to like it), and removes the menu headers; it also removes the ellipsis from the end of the Save file dialogs, since the Open ones don't have them, and it's consistent with what other GTK apps do). Feedback appreciated. :) --- dillo-0.6.1/src/commands.c Sun Aug 12 03:12:49 2001 +++ dillo-0.6.1-azz/src/commands.c Fri Sep 21 03:18:15 2001 @@ -115,7 +115,7 @@ GTK_SIGNAL_FUNC(gtk_widget_destroyed), &bw->viewsource_window); - gtk_window_set_title (GTK_WINDOW (window), "View Source"); + gtk_window_set_title (GTK_WINDOW (window), "View source"); gtk_container_border_width (GTK_CONTAINER (window), 0); box1 = gtk_vbox_new (FALSE, 0); @@ -139,7 +139,7 @@ gtk_text_insert (GTK_TEXT (text), NULL, NULL, NULL, buf, size); gtk_text_thaw (GTK_TEXT (text)); - button = gtk_button_new_with_label ("close"); + button = gtk_button_new_with_label ("Close"); gtk_signal_connect_object (GTK_OBJECT (button), "clicked", GTK_SIGNAL_FUNC(gtk_widget_destroy), GTK_OBJECT (window)); --- dillo-0.6.1/src/interface.c Fri Sep 21 02:31:12 2001 +++ dillo-0.6.1-azz/src/interface.c Fri Sep 21 03:20:07 2001 @@ -884,7 +884,7 @@ if (!bw->openfile_dialog_window) { Interface_make_choose_file_dialog( &(bw->openfile_dialog_window), - "openfile_dialog", "Dillo", "Dillo: Open File", + "openfile_dialog", "Dillo", "Dillo: Open file", (GtkSignalFunc) Interface_openfile_ok_callback, (void *)bw); } @@ -1144,7 +1144,7 @@ fflush(Web->stream); fstat(fileno(Web->stream), &st); fclose(Web->stream); - a_Interface_msg(Web->bw, "File saved (%d Bytes)", st.st_size); + a_Interface_msg(Web->bw, "File saved (%d bytes)", st.st_size); } else { if ( (Bytes = Client->BufSize - Web->SavedBytes) > 0 ) { Bytes = fwrite(Client->Buf + Web->SavedBytes, 1, Bytes, Web->stream); @@ -1231,7 +1231,7 @@ if (!bw->save_dialog_window) { Interface_make_choose_file_dialog( &bw->save_dialog_window, - "save_dialog", "Dillo", "Dillo: Save URL as File...", + "save_dialog", "Dillo", "Dillo: Save URL as file", (GtkSignalFunc) Interface_file_save_url, (void *)bw ); } url = a_Url_new(gtk_entry_get_text(GTK_ENTRY(bw->location)), NULL, 0, 0); @@ -1258,7 +1258,7 @@ Interface_make_choose_file_dialog( &bw->save_link_dialog_window, "save_link_dialog", "Dillo", - "Dillo: Save link as File...", + "Dillo: Save link as file", (GtkSignalFunc) Interface_file_save_link, (void *)bw); } --- dillo-0.6.1/src/menu.c Fri Jul 13 18:58:03 2001 +++ dillo-0.6.1-azz/src/menu.c Fri Sep 21 03:11:35 2001 @@ -124,15 +124,15 @@ /* FILE MENU */ file_menu = Menu_new(menubar, tiny ? "_F" : "_File", FALSE, bw); - Menu_add(file_menu, "_New Browser", "N", bw, + Menu_add(file_menu, "_New browser", "N", bw, a_Commands_new_callback, bw); - Menu_add(file_menu, "_Open File...", "O", bw, + Menu_add(file_menu, "_Open file...", "O", bw, a_Commands_openfile_callback, bw); Menu_add(file_menu, "Open _URL...", "L", bw, a_Commands_openurl_callback, bw); Menu_add(file_menu, "_Preferences", "E", bw, a_Commands_prefs_callback, bw); - Menu_add(file_menu, "Close _Window", "W", bw, + Menu_add(file_menu, "Close _window", "W", bw, a_Commands_close_callback, bw); Menu_sep(file_menu); Menu_add(file_menu, "E_xit Dillo", "X", bw, @@ -141,7 +141,7 @@ /* BOOKMARKS MENU */ bookmarks_menu = Menu_new(menubar, tiny ? "_B" : "B_ookmarks", FALSE, bw); bw->bookmarks_menu = bookmarks_menu; - Menu_add(bookmarks_menu, "_View Bookmarks", NULL, bw, + Menu_add(bookmarks_menu, "_View bookmarks", NULL, bw, a_Commands_viewbm_callback, bw); Menu_sep(bookmarks_menu); a_Bookmarks_fill_new_menu(bw); @@ -164,21 +164,18 @@ GtkWidget *menu; menu = gtk_menu_new(); - Menu_sep(menu); - Menu_add(menu, " PAGE OPTIONS", NULL, bw, NULL, NULL); - Menu_sep(menu); - Menu_add(menu, "View page Source", NULL, bw, + Menu_add(menu, "View page source", NULL, bw, a_Commands_viewsource_callback, bw); Menu_add(menu, "Bookmark this page", NULL, bw, a_Commands_addbm_callback, bw); Menu_sep(menu); - Menu_add(menu, "_Find Text", "F", bw, + Menu_add(menu, "_Find text", "F", bw, a_Commands_findtext_callback, bw); bw->pagemarks_menuitem = Menu_add(menu, "Jump to...", NULL, bw, NULL, bw); Menu_sep(menu); - Menu_add(menu, "Save page As...", NULL, bw, + Menu_add(menu, "Save page as...", NULL, bw, a_Commands_save_callback, bw); return menu; @@ -193,15 +190,12 @@ GtkWidget *copy; menu = gtk_menu_new(); - Menu_sep(menu); - Menu_add(menu, " LINK OPTIONS", NULL, bw, NULL, NULL); - Menu_sep(menu); - Menu_add(menu, "Open Link in New Window", NULL, bw, + Menu_add(menu, "Open link in new window", NULL, bw, a_Commands_open_link_nw_callback, bw); - Menu_add(menu, "Add Bookmark for Link", NULL, bw, + Menu_add(menu, "Add bookmark for link", NULL, bw, a_Commands_addbm_callback, bw); - copy = Menu_add(menu, "Copy Link location", NULL, bw, + copy = Menu_add(menu, "Copy link location", NULL, bw, a_Commands_set_selection_callback, bw); gtk_signal_connect(GTK_OBJECT(copy), "selection_clear_event", GTK_SIGNAL_FUNC(a_Commands_clear_selection_callback), NULL); @@ -211,7 +205,7 @@ GTK_SIGNAL_FUNC(a_Commands_give_selection_callback), NULL); Menu_sep(menu); - Menu_add(menu, "Save Link As...", NULL, bw, + Menu_add(menu, "Save link as...", NULL, bw, a_Commands_save_link_callback, bw); return menu; } -- Adam Sampson [Dillo-dev]Patch for better display of XHTML documents From: Adam Sampson - 2001-09-21 02:09 Hiya. Since XHTML documents are required to have an XML definition at the top and dillo's HTML parser considers to just be text, the XML definitions are visible in dillo's HTML view. This patch makes dillo treat as a tag; since it doesn't know what to do with [Dillo-dev]usability patch From: Martin Samuelsson - 2001-09-20 22:33 Attachments: dillo-userfriendly.patch i made these changes to make dillo a little more user friendly. it adds vi like key movement and makes it possible to completly remove the menubar. i am in no way saying that my patch is nice enough to get included, i'm not a coder. see it as inspiration on what end users want. what do you think? great work btw. the world really needs a browser like dillo. [Dillo-dev]Re: remote url access From: Sean MacLennan - 2001-09-20 03:29 Attachments: dillo-patch Hi! Way back on 10/20/2000 I posted a problem with trying to get Mosaic style remote urls working with dillo. Well, I tried it again with 0.6.1 and it works great! Attached is a patch to try it. For users of X?Emacs, the following allows you to try it with browse url: (setq browse-url-mosaic-program "dillo" browse-url-browser-function 'browse-url-mosaic) Thanks, Sean MacLennan Re: [Dillo-dev]Updated https patch available From: Aaron Lehmann - 2001-09-19 07:46 On Tue, Sep 18, 2001 at 10:34:17PM +0200, Tor-?ke Fransson wrote: > Finally fixed the POST method, and made https use the same query mechanism > as http. Which in turn means that my previous auth patch will work with > https also :) This is really cool!!! > Yesterday i managed reading webmail (IMP) on our corporate > intranet using auth and https in Dillo. Hotmail did not work though > (missing cookies) ;) I hope you'll do cookies next! :-) RE: [Dillo-dev]Updated https patch available From: Johannes Hofmann - 2001-09-19 07:21 Hi, thanks for these cool patches! https and auth work great on my box (FreeBSD 4.4) Cheers, Johannes [Dillo-dev]Updated https patch available From: - 2001-09-18 20:34 Finally fixed the POST method, and made https use the same query mechanism as http. Which in turn means that my previous auth patch will work with https also :) Yesterday i managed reading webmail (IMP) on our corporate intranet using auth and https in Dillo. Hotmail did not work though (missing cookies) ;) Https patch is at http://www.lysator.liu.se/~torkel/computer/ipaq/dillo_https.diff.gz ...applies cleanly with -p1 on my cvs tree from last thursday (i'm on a 56k modem!) ... oh, and you need OpenSSL. Regards, Tor-Åke [Dillo-dev]Bookmark Seperator patch completed From: DraX - 2001-09-17 02:11 Attachments: dillo_bookmarkseperator.patch Attached is my completed patch to add seperators to the bookmark system, it now uses
, instead of my deformed href stuff, and it follows the bookmark pattern more, which was required when i made it so all browsers would have seperators and not just the first. I hope everyone enjoys, and i hope it makes it into cvs! [Dillo-dev]seperator patch nearly complete From: DraX - 2001-09-16 19:53 ok http://www.stampede.org/~drax/commands.c menu.c bookmark.c work fine, except seperators aren't parsed by all browser windows, only the first, ie if i start a new window, it dosen't have seperators, except if i add them from the menu. That and i want to change it from using a deformed A HREF to using HR, ubt that will take some modifiying to the way it parses the bookmark file. Try them out, fix the bugs if you want, and as soon as they're all fixed i'll submit a real patch. [Dillo-dev]Impl. Basic auth (patch available) From: - 2001-09-16 19:40 My post this thursday seems to have disappeared somewhere. (not in the mail archive) I'll try again: ------------------------------------------------- Hi all. I rethinked the authentication scheme a bit. (No changes to DilloUrl) It now keeps a list of the base url's for which auth info exists, instead. Gui code is in place, and all in all it works pretty ok. The 401 page is displayed before the reload though. Not so nice. How do i stop dillo from displaying it before the user have had a chance to authenticate? I could load another (empty) page, but i want to keep the 401 page for displaying, should the user/pass be wrong. Patch is at http://www.lysator.liu.se/~torkel/computer/ipaq/dillo_auth.diff.gz The patch is against todays (thursday) CVS and should apply cleanly w/ -p1. Even remembered to change the Makefile.in this time ;) I will post an updated https patch soon. Having trouble with POST. Regards, Tor-Åke [Dillo-dev]Seperator is now working From: DraX - 2001-09-16 18:56 the address in my last email now has a working seperator bookmark file, just need to add a "Add Seperator" menu option and then i'll make a patch. [Dillo-dev]Adding seperator to bookmarks From: DraX - 2001-09-16 18:39 out of boredom i started to modify on the bookmark system to allow seperators, by using a line like: SEP-ER-RATOR Now i got it to the point where it can detect a "Seperator" call and not list the seperator in the bookmark list, but my minimal c/gtk skills are not giving me a way to put a seperator in. I tried using Menu_sep(), but that didn't exactly work, more like it gave me a resolution error on compile. http://www.stampede.org/~drax/bookmark.c includes the bookmark code modified to check for SEP-ER-RATOR, if anyone could help me out with making this all acutlly work. I've decided to help out with dillo, i'd fix up the bookmark manager, even have a nice little listview interface, and possibly add support for netscape style bookmarks, and maybe even XBEL. Any help getting this first patch completed would be much obliged, it's messy i know, i'll clean it up when i get it working :) [Dillo-dev]Patch Manager ala bug manager From: DraX - 2001-09-16 16:28 I was thinking it would be nice if we had a patch manager, that allowed people to submit there patches to it, so anyone could download and comment on them, this would give a central place to find pending features, and would just be sort of nice to have! I could do one in PHP, if you need someone to do it. Alex RE: [Dillo-dev]about dillo From: Eric GAUDET - 2001-09-15 17:36 Hi, dillo still have a lot of debug messages printed in stdin. You should be able to retrieve the lines looking like: Nav_open_url: Url=>http://dillo.so....net/< If you really want it in a file (say ~/.dillo/dillo.history), just launch dillo with: dillo > ~/.dillo/dillo.history And if you *really* want *only* the urls, just lanch dillo with: dillo | grep Nav_open_url > ~/.dillo/dillo.history Best, Eric -- En reponse de "[Dillo-dev]about dillo" de Manolo, le 15-Sep-2001 : > > > > Hello. > > I want to suggest something. > > Because Dillo crashes sometimes -few- when i use it, its possible > include a "history" option for a more quick finding for the last > site that you visited before crashing? > > A lot of thanks. > > Salutations. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@li... > https://lists.so....net/lists/listinfo/dillo-dev ------------------------------------ Eric GAUDET Le 15-Sep-2001 a 10:26:04 "In theory, there's no difference between theory and practice; in practice, there is." ------------------------------------ [Dillo-dev]about dillo From: Manolo - 2001-09-15 14:56 Hello. I want to suggest something. Because Dillo crashes sometimes -few- when i use it, its possible include a "history" option for a more quick finding for the last site that you visited before crashing? A lot of thanks. Salutations. [Dillo-dev]0.6.1 release From: Jorge Arellano Cid - 2001-09-14 04:03 Hi everybody! Tonight I just released dillo-0.6.1! Please don't think that the before submitted patches were rejected; they're simply waiting for a second revision, or probably further improvement. Ah, FYI there're also a couple of new links on the web site: check the [Art] link for some neat images and the 'Free Software' in the [Links] section, for an interesting reading. Regards Jorge.- [Dillo-dev]meta refresh From: Viksell - 2001-09-13 19:36 Attachments: patch-meta Hi all! I noticed bug #208 (meta refresh) and remembered that I did a fix for this a while ago. One thing I'm concerned about is if refresh times of zero should be allowed since it may be abused. Or it can be used to stress-test Dillo! ;-) As a bonus (or not) I'm throwing in a fix that I think is handy: Allowing forms with only one text-type input to be submitted by pressing enter, even if they have submit button(s). It seems to be standard behaviour in most browsers. If the form has more than one text input the next element is focused... Patch attached since FTP is playing up on me, Cheers, J=F6rgen Re: [Dillo-dev]Implementing Basic authentication From: Viksell - 2001-09-12 00:43 On Tue, 2001-09-11 at 23:24, Tor-=C5ke Fransson wrote: >=20 > What other useful features are not worked on? Cookies? I'm working on cookies.=20 The old Netscape style cookies (version 0) works, except for some problems with timezones that has to be fixed. Version 1 cookies are about half-way done. At the moment, Dillo can't parse multiple set-cookie or set-cookie2 responses in the HTTP header, so that also has to change to make everything work. // J=F6rgen [Dillo-dev]Implementing Basic authentication From: - 2001-09-11 23:24 Hi all. To avoid duplicate efforts: is anyone implementing authentication? In either case i have been working on it for the last three days. Works like this: DilloUrl gets an extra attribute, Auth. The 401 return code is trapped in the cache (same place as 30x) and user is asked for username/password. Auth for the url that caused 401 is set to base64 encoded user/pass and a force reload is issued as for redirects. In html.c all places where DilloUrl's are created, they are checked for relativeness, and if so, they get Auth copied from the base url, so user/pass does not have to be entered for every object loaded. http.c checks for Auth in the url when creating the query, and if Auth is non-null, the query gets an extra line with authentication info. The performance to browsing unauthenticated is 5 extra lines of code executed per link/image on a page, and memory usage is up sizeof(GString *) for every DilloUrl created. This will be quite a big patch when finished (Gui gtk+ code remaining) and it will also affect my earlier https patch. ETA is this weekend. (if noone wants to look at it right now) What other useful features are not worked on? Cookies? Regards, Tor-Åke Re: [Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts) From: Eric GAUDET - 2001-09-11 02:21 FYI, the answer I had from gtk's mailining list: -- FW GTK takes strings in the encoding of the current locale. If you give it anything else, then your code is broken; it won't work in all locales. Your code works on Red Hat because the locale happens to be en_US or the like which uses Latin-1; on Debian in the "C" locale the encoding is ASCII, Latin-1 is not allowed. If you are hardcoding Latin-1 strings into your app, then you require a Latin-1 locale to run and work. It's that simple. Even if by some bad hack we could make it work in ASCII, it would be totally broken in every other non-Latin-1 locale. The usual way to solve this problem - make strings match the locale - is to translate them with gettext. GTK 2 will require every string to be in UTF-8. Also, Red Hat will probably move to all locales using the UTF-8 encoding at some point, so Latin-1 will not work even in en_US or fr_FR. Point being, in the future hardcoded Latin-1 strings won't work even in the locales that are currently Latin-1. Havoc -- end FW -- En reponse de "Re: [Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)" de Hugo Hallqvist, le 03-Sep-2001 : > On Mon, 03 Sep 2001 12:51:23 -0700 (PDT) > Eric GAUDET wrote: > >> I think I can investigate this problem, because a I can reproduce it both >> ways: >> - my personal computer is a (heavily customised) mandrake 6.2, and I have no >> problem displaying characters in the forms. >> - my computer at work is a debian, and I have the same problem Hugo has, >> with >> all non-ascii entities, for all form elements. For instance: > > That is one common thing between us, my computer is running debian > unstable/testing, so I guess that should have something to do with it? > > >>
>> >>
>> will show an empty box, while value="abc&" will of course show "abc&" >> >> And that's a problem for me too, even if I don't speak swedish, because my >> primary language is french, which uses é a lot. > > Have you tried gtk_set_locale() and if you have; did it work then? > > -- > //Hugo Hallqvist - hugha495@st... ------------------------------------ Eric GAUDET Le 10-Sep-2001 a 19:19:00 "In theory, there's no difference between theory and practice; in practice, there is." ------------------------------------ Re: [Dillo-dev]Bugs in URLs (+ bug #194 + viewing Slashdot.org) From: Eric GAUDET - 2001-09-09 06:46 -- En reponse de "Re: [Dillo-dev]Bugs in URLs (+ bug #194 + viewing Slashdot.org)" de Jorge Arellano Cid, le 08-Sep-2001 : > > Hi, > >> [...] >> I've sent this to >> Jorge already, but since more people here enjoy slashdot.org with CVS >> Dillo, the patch is at: >> >> http://www.linux.ime.usp.br/~livio/dillo/url.fix.999873136.diff > > I just uploaded a modified patch to CVS. > Well, I just tested it and I'd say we have a pretty good v0.6.1 ! A nice "cherry on the cake"-feature would be one of the two lynx-style frames patches. I tryed both and both seem to do the trick. I kinda like better Livio's version, not for what they do (they look the same to me), but Livio's code seem much cleaner (way to go, Livio :-) Best, ------------------------------------ Eric GAUDET Le 08-Sep-2001 a 23:35:59 "In theory, there's no difference between theory and practice; in practice, there is." ------------------------------------ Re: [Dillo-dev]Bugs in URLs (+ bug #194 + viewing Slashdot.org) From: Jorge Arellano Cid - 2001-09-08 23:13 Hi, > [...] > I've sent this to > Jorge already, but since more people here enjoy slashdot.org with CVS > Dillo, the patch is at: > > http://www.linux.ime.usp.br/~livio/dillo/url.fix.999873136.diff I just uploaded a modified patch to CVS. Greetings Jorge.- [Dillo-dev][PATCH] Merging frame patches (w3m-style :) From: Livio Baldini Soares - 2001-09-08 22:49 Hi guys, since I'm very interested in this minimal frame support, I've decided to try to make my "merged" version of this patch. I loosely based this on a patch sent by Robert J Thomson and Hugo Hallqvist last patch. Well loosely because my implementation is a bit diferent. I'm a w3m fan (www.w3m.org), and it's frame support is very similar to lynx's, but when in nested frameset's, you can see it visually, as it makes nested lists. So this what I have done. The patch is, I think, pretty much clean, and is easily removable/replaceable. I would like to hear comments for improvement (specially from Hugo and Robert), before I send this off to Jorge. I don't believe there are any bugs, the patch is really simple. I've browsed through several framed sites, and haven't got any styles left over. The patch is at: http://www.linux.ime.usp.br/~livio/dillo/w3m_frames.999984467.diff PS: The reason I think this temporary fix is worth pursuing is because the real frame support can take a long time before finished. I personally think it will because it's a very hard feature to implement (I guess harder than tables). And also, this adds no code overhead on Dillo. It can be removed and replaced very easily when real frame support is done. Does anyone have anything against this patch? best regards to all, -- Livio RE: [Dillo-dev]bug #207, too long attributes From: Eric GAUDET - 2001-09-08 02:09 -- En reponse de "[Dillo-dev]bug #207, too long attributes" de J=F6rgen V= iksell, le 08-Sep-2001 : > Hi all! >=20 > Just thought I should mention that bug #207 seems to happen because of = a > too long attribute ( that Jorge gave his view on earlier. > Is anyone working on this? I am willing to help but I'm not sure where > to start. >=20 > J=F6rgen >=20 It seems the problem is fixed with the patch for long attributes I submit= ted to Jorge, which is: diff -pur dillo/src/html.c dillo.longurl/src/html.c --- dillo/src/html.c Mon Aug 27 14:44:12 2001 +++ dillo.longurl/src/html.c Tue Aug 28 23:10:34 2001 @@ -3290,8 +3288,7 @@ static gint Html_match_attr(const char * static gint Html_get_attr_value(const char *tag, gint tagsize, char *data, gint datasize, gint strip) { - gint i =3D 0, j =3D -1, max =3D MAX(tagsize, datasize); + gint i =3D 0, j =3D -1, max =3D MIN(tagsize, datasize); =20 if (tag[0] =3D=3D '"' || tag[0] =3D=3D '\'' ) { for (i =3D 1; strip && i < max && isspace(tag[i]); i++) >=20 > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@li... > https://lists.so....net/lists/listinfo/dillo-dev ------------------------------------ Eric GAUDET Le 07-Sep-2001 a 19:07:23 "In theory, there's no difference between=20 theory and practice; in practice, there is." ------------------------------------ [Dillo-dev]lynx frames again From: Hugo Hallqvist - 2001-09-08 00:35 Attachments: lynx-frames.patch Hi! Thanks for the tips of how the style stuff in dillo works, especially Bob. I'm sure I have not fully understand it but yet here's a revised version of my patch. It is more stable now, atleast that's my impression. Please feel free to enhance it, as I am sure it could be better written, at least the styles stuff. If I understood it correctly every page_add_text() adds 1 to the reference counter right? if so, one should be able to do style_unref directly after using the add_text function, however it won't work for me, just segfaulting if I do so. Maybe I did not understand it fully. Also, anyone know something about bug #204? It seems very sporadeosly, ehmm, I mean it shows up sometimes, sometimes not on the same page. Is this related to the contents of the page or is it something in dillo? -- //Hugo Hallqvist - hugha495@st... [Dillo-dev]Feature: don't load images [PATCH] From: - 2001-09-07 23:15 Attachments: dillo_noimg.diff In my despair over not beeing able to figure out how to load pages with large images without running out of memory on my ipaq, i instead added an option to not load images at all. Ideally, i would like a way to not load all images on a page, should the page contain many large images, but instead cached uncompressed, and then uncompressed as they become exposed. Or simply a memory consumption high water mark whereover, image loading is automatically turned off. Better than running out of memory! Anyway... the included diff (against cvs of right now) adds this: Images on/off can be toggled from the menu (File menu, unfortunately, but in the abscence of a preferences dialogue it'll have to do). When images are off, the image url is replaced by a user-selectable url (dillorc) and then loaded. This means eventual alt= tags still cause a tooltip popup. Imagemaps will behave strange, but the code seemed to indicate they are quite broken anyway. Regards, Tor-Åke Fransson [Dillo-dev]bug #207, too long attributes From: Viksell - 2001-09-07 23:05 Hi all! Just thought I should mention that bug #207 seems to happen because of a too long attribute ( - 2001-09-07 16:02 Hi Sebastian, Sebastian Geerken writes: > Hi, > > there are some more bugs in URLs. I've written a small test program, > attached to this mail. Just compile > > cc -o test-url `glib-config --cflags --libs` test-url.c url.c > > and start it. (-: Wow.... nice little test program. Thanks to that I've made a "correct" (heheh, at least I think) fix the the URL problem at slashdot.org. It seems that both Bruno's and my patch were a little wrong and broke some URLs with `file:/` scheme. I've sent this to Jorge already, but since more people here enjoy slashdot.org with CVS Dillo, the patch is at: http://www.linux.ime.usp.br/~livio/dillo/url.fix.999873136.diff Please test it and send me feedback if you see that it doesn't work correctly on a particular page or link. best regards to all, -- Livio Re: [Dillo-dev]How to add a link to a page? From: Sebastian Geerken - 2001-09-07 12:51 Hi Hugo, On Thu, Sep 06, 2001 at 03:33:53PM +0200, Hugo Hallqvist wrote: > On Wed, 05 Sep 2001 19:37:24 -0300 > Livio Baldini Soares wrote: > [...] > > changing the style of the link (change the color to X if link is > > visited or Y if not, make it underlined, etc). > > This is where I start to get problems. If I want to use a style just briefly and then revert back to the style used before? > I copied some of the code from tag_a code and used it, and it displays correctly, but I get warnings on closing dillo that there are styles left. > > > I'm really interested in this patch, and I'd be really glad if I > > could help you out more (if you want we could make this patch > > together -- but feel free to do it alone if you want that too). > > What is the style I send to a_Dw_style_new function? I did not quite > understand that. There are some notes in doc/DwStyle.txt, but nothing about the HTML parser. You must fill a DwStyle structure (except the ref_count), and call a_Dw_style_new, to use it: DwStyle style_attrs, *style; style_attrs.foo = bar; // etc. style = a_Dw_style_new (&style_attrs, random_window); // do something with style After this, the attributes of style should not be changed anymore, since styles are often shared between different widgets etc. Most times, you simply copy the attributes of another style, and modify them: style_attrs = *another_style; style_attrs.foo = bar; style = a_Dw_style_new (&style_attrs, random_window); Some words about the stack: the topmost element contains a (reference to a) style which will be used to add the text to the current page. If you use a style only for a short while (e.g. in this case), you may use it this way: style_attrs = *html->stack[html->stack_top].style; style_attrs.foo = bar; style = a_Dw_style_new (&style_attrs, random_window); a_Dw_page_add_text will add a reference to it, so you must unref it at the end of Html_tag_open_frame. Just for completeness: In many cases, you want to set the style for the content of an element (e.g. ), then you must store it in the stack, look at the macro HTML_SET_TOP_ATTR. But this is not necessary in this case. > Also, why does dillo crash if I add a few lines of text, using the a_Dw_page_add_text in a function, even though I haven't touched anything else? > I get a segmentation fault directly when I click a link if I use that function, see the Html_tag_open_frameset function for example. As far as I see, a style with a reference count of zero (which is so freed!) is used. Sebastian Re: [Dillo-dev]table rendering on futurezone.orf.at From: Sebastian Geerken - 2001-09-07 12:09 On Fri, Sep 07, 2001 at 12:10:12PM +0200, Ulrich Schwarz wrote: > Hi, > > here's another issue about futurezone.orf.at rendering. > > After the nowrap/width rendering problem was fixed, I've now found a > strange two-column rendering of the first paragraph on > Futurezone-subpages in dillo whereas other browsers use only one > column-rendering there. > > e.g. > http://futurezone.orf.at/futurezone.orf?read=detail&id=80073&tmp=71566 > http://futurezone.orf.at/futurezone.orf?read=detail&id=80131&tmp=5807 > etc. I've tested the first one and found a violation: before the table cell with the text "Nach jahrelangen juristischen Konflikten ..." (the one which is positioned wrong), you'll find a , but no , just "", so dillo does not add a new row. BTW, this behavior was different some time ago, but was changed for handling pages with ". Sebastian [Dillo-dev]table rendering on futurezone.orf.at From: Ulrich Schwarz - 2001-09-07 10:13 Hi, here's another issue about futurezone.orf.at rendering. After the nowrap/width rendering problem was fixed, I've now found a strange two-column rendering of the first paragraph on Futurezone-subpages in dillo whereas other browsers use only one column-rendering there. e.g. http://futurezone.orf.at/futurezone.orf?read=detail&id=80073&tmp=71566 http://futurezone.orf.at/futurezone.orf?read=detail&id=80131&tmp=5807 etc. So long. Ulrich Re: [Dillo-dev]How to add a link to a page? From: Jason Kibblewhite - 2001-09-06 20:53 On Thu, Sep 06, 2001 at 03:33:53PM +0200, Hugo Hallqvist wrote: > On Wed, 05 Sep 2001 19:37:24 -0300 > Livio Baldini Soares wrote: > > What is the style I send to a_Dw_style_new function? I did not quite understand that. > Also, why does dillo crash if I add a few lines of text, using the a_Dw_page_add_text in a function, even though I haven't touched anything else? > I get a segmentation fault directly when I click a link if I use that function, see the Html_tag_open_frameset function for example. > > Anyway, here is a first version. Feedback on stability welcome. :-) > I don't frequent very many frames sites so it was hard to find places to test this. Some sites such as google's image browers produced instand segfaults without even giving me a change to click on a link, while still others such as http://www.tragicallyhip.com segfault when I put the mouse over the link, however the latter does work if I run dillo through strace. I'm not much of a C coder so I couldn't even begin to explain that. Nice work, even heavy frames pages like securityfocus.com work well. -- All language designers are arrogant. Goes with the territory... -- Larry Wall Re: [Dillo-dev]How to add a link to a page? From: Hugo Hallqvist - 2001-09-06 13:29 Attachments: frames-lynx.patch On Wed, 05 Sep 2001 19:37:24 -0300 Livio Baldini Soares wrote: > Wow! What a nice idea! I should of thought of that :-) It's a great > workaround (and should be real easy to implement too!) before real > frame support (which isn't easy at all :(, is complete. Yes, hopefully it will add some functionality, so one doesn't have to cut and paste so much. > Well, to add a link to a page you should first create and initialize > a DilloURL struct (using a_Url_new(url_string, base_url_string) from > src/url.c). Done, this was the easy part. :-) > This URL will contain the destination that the link will point > to. Then with the DilloURL, you should add it to the page, using > Html_new_link(html, url). This will add a new link in the DilloHtml's > linkblock (which is a list, like, html->linkblock->links[n]), the > Html_new_link() will return the index (n) of the link in the > linkblock->links array. Eventually you may want that index for Done too, didn't see that one at first in tag_a code. > changing the style of the link (change the color to X if link is > visited or Y if not, make it underlined, etc). This is where I start to get problems. If I want to use a style just briefly and then revert back to the style used before? I copied some of the code from tag_a code and used it, and it displays correctly, but I get warnings on closing dillo that there are styles left. > I'm really interested in this patch, and I'd be really glad if I > could help you out more (if you want we could make this patch > together -- but feel free to do it alone if you want that too). What is the style I send to a_Dw_style_new function? I did not quite understand that. Also, why does dillo crash if I add a few lines of text, using the a_Dw_page_add_text in a function, even though I haven't touched anything else? I get a segmentation fault directly when I click a link if I use that function, see the Html_tag_open_frameset function for example. Anyway, here is a first version. Feedback on stability welcome. :-) -- //Hugo Hallqvist - hugha495@st... [Dillo-dev]0.6.1-pre From: Johannes Hofmann - 2001-09-06 07:44 Hi, just want to say, that dillo 0.6.1-pre feels a lot more stable than 0.6.0. Just the latest CVS version (updated Sep 5 18:16) crashes on http://www.oreillynet.com. thanks, Johannes PS: I am running FreeBSD 4.3. Some info from the core file: bash-2.05$ gdb dillo dillo.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... Core was generated by dillo'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libpng.so.4...done. Reading symbols from /usr/lib/libz.so.2...done. Reading symbols from /usr/X11R6/lib/libgtk12.so.2...done. Reading symbols from /usr/X11R6/lib/libgdk12.so.2...done. Reading symbols from /usr/local/lib/libgmodule12.so.3...done. Reading symbols from /usr/local/lib/libglib12.so.3...done. Reading symbols from /usr/local/lib/libintl.so.1...done. Reading symbols from /usr/lib/libxpg4.so.3...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/local/lib/libjpeg.so.9...done. Reading symbols from /usr/lib/libc_r.so.4...done. Reading symbols from /usr/X11R6/lib/libXThrStub.so.6...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x8053811 in Cache_redirect (entry=0x80d5030, Flags=1, bw=0x8093500) at cache.c:643 643 NewUrl = a_Url_new(URL_STR(entry->Location),URL_STR(entry->Url),0,0); (gdb) p *entry $1 = {Url = 0x0, Type = 0x21
, Header = 0xb, Location = 0x3, Data = 0x0, ValidSize = 0, TotalSize = 4, BuffSize = 5, Flags = 28, io = 0x0, CCCQuery = 0x24, CCCAnswer = 0xb} Re: [Dillo-dev]How to add a link to a page? From: Livio Baldini Soares - 2001-09-05 22:37 Howdy Hugo! Hugo Hallqvist writes: > Hi everyone! > > I'm wondering how I should go about to add a link to a page in > dillo. I try to patch dillo to put up a link when framed pages are > viewed, so that I can click on one of them to view the page, just > like in lynx. Wow! What a nice idea! I should of thought of that :-) It's a great workaround (and should be real easy to implement too!) before real frame support (which isn't easy at all :(, is complete. > I looked at the tag_open_a but I cannot fully understand how the > links are added to the page and most of all displayed. Well, to add a link to a page you should first create and initialize a DilloURL struct (using a_Url_new(url_string, base_url_string) from src/url.c). This URL will contain the destination that the link will point to. Then with the DilloURL, you should add it to the page, using Html_new_link(html, url). This will add a new link in the DilloHtml's linkblock (which is a list, like, html->linkblock->links[n]), the Html_new_link() will return the index (n) of the link in the linkblock->links array. Eventually you may want that index for changing the style of the link (change the color to X if link is visited or Y if not, make it underlined, etc). I think that's about it. Although, probably I'm forgetting something. I'm really interested in this patch, and I'd be really glad if I could help you out more (if you want we could make this patch together -- but feel free to do it alone if you want that too). best regards! -- Livio [Dillo-dev]How to add a link to a page? From: Hugo Hallqvist - 2001-09-05 22:09 Hi everyone! I'm wondering how I should go about to add a link to a page in dillo. I try to patch dillo to put up a link when framed pages are viewed, so that I can click on one of them to view the page, just like in lynx. I looked at the tag_open_a but I cannot fully understand how the links are added to the page and most of all displayed. If someone would make a brief explanation I would be grateful. -- //Hugo Hallqvist - hugha495@st... [Dillo-dev]Bugs in URLs From: Sebastian Geerken - 2001-09-05 12:55 Attachments: test-url.c Hi, there are some more bugs in URLs. I've written a small test program, attached to this mail. Just compile cc -o test-url `glib-config --cflags --libs` test-url.c url.c and start it. Sebastian Fw: Re: [Dillo-dev]0.6.1-pre From: Hugo Hallqvist - 2001-09-05 06:32 On Tue, 04 Sep 2001 19:13:00 -0700 (PDT) Eric GAUDET wrote: I think so too. Regarding the stability I haven't noticed a single crash, and I've used it almost exclusively. Some images don't get loaded properly, however. I also noticed it consumes large amounts of memory after a while, as most I got up to 100 MB in memory consumption before I restarted dillo. Anyone know what the status of tabs, \n and \r support in 
 tags is? They to shows up as dotted-boxes here, for example in dillo changelog.

> IMHO we really need the url begining with "//" patch for next release:
> slashdot's page is looking worse than ever.
> 
> > Do you remember my "Yesterday commit" post? It asked for some
> > feedback on latest CVS stability; only Livio has answered. This
> > is necessary before 0.6.1 release, because I need to know if it
> > feels more stable than 0.6.0 or //Hugo Hallqvist - hugha495@st....
-- 
//Hugo Hallqvist - hugha495@st... 



RE: [Dillo-dev]0.6.1-pre

From: Eric GAUDET  - 2001-09-05 02:13

IMHO we really need the url begining with "//" patch for next release:
slashdot's page is looking worse than ever.

-- En reponse de "[Dillo-dev]0.6.1-pre" de Jorge Arellano Cid, le 04-Sep-2001 :
> 
> Hi everyone!
> 
> 
> Do you remember my "Yesterday commit" post? It asked for some
> feedback on latest CVS stability; only Livio has answered. This
> is necessary before 0.6.1 release, because I need to know if it
> feels more stable than 0.6.0 or not.
> 
> Thanks
> Jorge.-
> 
> 
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev@li...
> https://lists.so....net/lists/listinfo/dillo-dev

------------------------------------
Eric GAUDET 
Le 04-Sep-2001 a 19:11:46
"In theory, there's no difference between 
theory and practice; in practice, there is."
------------------------------------ 



[Dillo-dev]OpenBSD user(s) read this

From: DraX  - 2001-09-04 22:28

Heh, if i can found out who it is :)

To OpenBSD user(s): if you posted bug 200 please reply to me on the list
or in private. 



[Dillo-dev]0.6.1-pre

From: Jorge Arellano Cid  - 2001-09-04 20:59

Hi everyone!


Do you remember my "Yesterday commit" post? It asked for some
feedback on latest CVS stability; only Livio has answered. This
is necessary before 0.6.1 release, because I need to know if it
feels more stable than 0.6.0 or not.

Thanks
Jorge.- 



Re: [Dillo-dev]Tiny memory leak with DilloImages (and HRuler proposal)

From: Jorge Arellano Cid  - 2001-09-04 19:04

Livio,

> Hello!
>
> Jorge, I've been chasing, what seems to be, a tiny (rare) memory
> leak in the Html_tag_open_img(). It allocates a DilloImage (with
> a_Image_new()). I believe this gets freed with the a_Dicache_close()
> or on abort with a_Dicache_callback(). I was trying local browsing and
> I think this might be causing some leakage, when the image is _not_
> found. If the image is not found, it doens't get an dicache entry,
> right?

Right!

> So this DilloImage is never freed... If my reasoning is
> somewhat correct, than this should free those DilloImages:
>
> [patch here]
>
> -----------
>
> Or some other, more generic, mechanism...

Yes, that structure should be freed within the stopping chain,
not in the html parsing module. It took me several days to find a
way of doing it that way!

Currently the dicache bindings are mainly hacks that get the
job done. BTW, if image loading is stopped, not only the Image
structure is not freed, but also the image decoding data, ditto
for abort.

This dicache part needs a design review, but beware, it
requires deep understanding of the whole CCC process. In general
terms, from the cache and down (CCC realm), things are handled
properly. Between the cache and Dw, there's a hacking breach!

...and as you may guess, priorities have it almost forgotten :(

> About the HRulers in Dillo, they have been bugging a bit. It seems
> that they don't create some space around them, and therefore renders
> some pages in a "tight" manner.
> [...]

Sebastian commited that
(this is a delayed answer).


Regards.- 



[Dillo-dev]entities parsing?

From: Hugo Hallqvist  - 2001-09-04 10:06

Hi everyone!

When browsing around a few sites today, I saw one that creates a few dotted boxes in dillo. Everyone seems to be entities.
http://www.msnbc.com/news/621347.asp?0dm=N14MT&cp1=1

Is this bad html, or is the entities list in dillo incomplete?

Most notably the asterisks, minus and apostroph (sp?) doesn't get correctly parsed.

-- 
//Hugo Hallqvist - hugha495@st... 



[Dillo-dev]Possibility of having dillo  open a url in the current instance

From: DraX  - 2001-09-03 21:25

What are the possibilityes of having dillo called with dillo  open a
url in a currently running version of dillo? 



Re: [Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)

From: Hugo Hallqvist  - 2001-09-03 20:14

On Mon, 03 Sep 2001 12:51:23 -0700 (PDT)
Eric GAUDET  wrote:

> I think I can investigate this problem, because a I can reproduce it both ways:
> - my personal computer is a (heavily customised) mandrake 6.2, and I have no
> problem displaying characters in the forms.
> - my computer at work is a debian, and I have the same problem Hugo has, with
> all non-ascii entities, for all form elements. For instance:

That is one common thing between us, my computer is running debian unstable/testing, so I guess that should have something to do with it?


> 
 
> 
> 
> will show an empty box, while value="abc&" will of course show "abc&"
> 
> And that's a problem for me too, even if I don't speak swedish, because my
> primary language is french, which uses é a lot.

Have you tried gtk_set_locale() and if you have; did it work then?

-- 
//Hugo Hallqvist - hugha495@st... 



RE: [Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)

From: Eric GAUDET  - 2001-09-03 19:51

-- En reponse de "[Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)" de
Jorge Arellano Cid, le 03-Sep-2001 :
> [Hugo wrote]
> 
>> I got problems with swedish (international?) characters in
>> buttons and in lists. The characters for example ä shows up
>> properly in the usual text on a page, but no when they are to be
>> added in the dropdownlist in a form or as a button in a submit
>> form.
> 
> They work for me!
> 

I think I can investigate this problem, because a I can reproduce it both ways:
- my personal computer is a (heavily customised) mandrake 6.2, and I have no
problem displaying characters in the forms.
- my computer at work is a debian, and I have the same problem Hugo has, with
all non-ascii entities, for all form elements. For instance:

 


will show an empty box, while value="abc&" will of course show "abc&"

And that's a problem for me too, even if I don't speak swedish, because my
primary language is french, which uses é a lot.

Both computers are set LANG=en and LC_ALL not set.

More info tomorrow, when I'm at my office.
Meanwhile, I will volunteer for this bug in the bugtrack engine.

> When visiting the page you suggested, I had no problems at all;
> every character showed up properly. Note that I use dillo without
> a gtk_set_locale() call (same as 0.6.0 release and CVS), and my
> environment has:
> 
> LC_ALL=POSIX
> LANG=C
> 
> Probably you have a swedish setting there (that's not a problem
> though!).
> 
> Please correct me if I'm wrong: The main reason for not
> including the gtk_set_locale() call in dillo, is that as dillo
> works in latin1, and as GTK+ handles strings in the multibyte
> encoding for the locale, a different locale encoding may result
> in inconsistencies in character handling.
> 
> Note: ISO C says that all programs start by default in the
> standar 'C' locale, so no explicit setting is required.
> 
> 
> IN BRIEF: check out the above hints, and please confirm me that
> you've got it working. If not, please ask Karsten, or some other
> swedish users, and answer back to this list (this time I'll
> reply quickly, because this subject is now on its turn).
> 
> 
------------------------------------
Eric GAUDET 
Le 03-Sep-2001 a 12:42:11
"In theory, there's no difference between 
theory and practice; in practice, there is."
------------------------------------ 



[Dillo-dev]antialiased dillo

From: Johannes Hofmann  - 2001-09-03 18:51

Hi,

using gdkxft (http://philrsss.anu.edu.au/~josh/gdkxft/) dillo can render
antialiased fonts now!
Well, it gets pretty slow then :-( but it's fun.

Cheers,
Johannes. 



[Dillo-dev]Missing feature

From:  - 2001-09-03 17:30

Hi all,

first a great thanks to all developer of dillo !
I'm using dillo since 0.3, version 0.6 works for
me in most cases.

But i really miss the possibility to browse through
ftp sides. I dont't need any download features,
nt does his work very well.

Any ideas ... ?

Greetings
Jürgen

-- 
juergen.daubert@t-... 



[Dillo-dev]BUG#199 (was: dillo patch for Fugly Fonts)

From: Jorge Arellano Cid  - 2001-09-03 15:16

Hi,

This is an issue a wanted to answer from a long time, now is
its turn, so lets get into it:

> Karsten had told me that without this patch he gets boxes instead of
> propper text.
> [...]
>
> This is bad coding style -- it's a kluge, not a fix.
>
> The problem is that search sequence for fonts is arbitrary, and ISO10646
> fonts can appear before ISO8859 fonts. Gtk doesn't handle ISO10646
> fonts properly, hence the resolution problems.
>
> The fix I've applied is to hardcode the font encoding into the font
> search string in dw_style.c.

Note that although Karsten thinks his patch is not a clean fix,
given current internal character handling in dillo (and to a
lesser extent GTK+), it's very close to what's required.

Dillo works in ISO-LATIN1; every page is encoded using it (for
further details, refer to [Project Notes]), so, the idea of
making an explicit request for the appropriate fonts is OK AFAIK.

The only change I'd make is to raise a warning if latin1 fonts
are not found, and to try to load the generic ones, so at least
dillo can be started.


[Hugo wrote]

> I got problems with swedish (international?) characters in
> buttons and in lists. The characters for example ä shows up
> properly in the usual text on a page, but no when they are to be
> added in the dropdownlist in a form or as a button in a submit
> form.

They work for me!

When visiting the page you suggested, I had no problems at all;
every character showed up properly. Note that I use dillo without
a gtk_set_locale() call (same as 0.6.0 release and CVS), and my
environment has:

LC_ALL=POSIX
LANG=C

Probably you have a swedish setting there (that's not a problem
though!).

Please correct me if I'm wrong: The main reason for not
including the gtk_set_locale() call in dillo, is that as dillo
works in latin1, and as GTK+ handles strings in the multibyte
encoding for the locale, a different locale encoding may result
in inconsistencies in character handling.

Note: ISO C says that all programs start by default in the
standar 'C' locale, so no explicit setting is required.


IN BRIEF: check out the above hints, and please confirm me that
you've got it working. If not, please ask Karsten, or some other
swedish users, and answer back to this list (this time I'll
reply quickly, because this subject is now on its turn).


> I experimented a little and dillo parses the entities
> correctly, the string puts out nicely in the xterm window, but
> gtk doesn't seem to like it when it is to add the
> component(button for example).
>
> Maybe this has something to do with the gtk_set_locale thing?

[answered above]

> It is reported as bug #199.


Regards
Jorge.- 



[Dillo-dev]Dillo Square Fonts

From: Jon Bradley  - 2001-09-03 08:27

I'm not sure if you can help me, I'm having a problem with dillo, atleast
I've only seen this happen with the dillo program. Running dillo 0.6.0,
and also the latest dillo CVS; the font letters, no matter what website,
look like little square boxes, there is actually no readable character at
all, just little square boxes in the correct font size.

I noticed this after upgrading from X 4.0.1 binaries, to X 4.0.3 compiled
and built by me on the local machine. Any recommendations on what to do
about this?

TIA.
=-=-=-=-=-=-=-=-=-=-=-=
Email: kreator@gc...
bbs: telnet://toga.cx
=-=-=-=-=-=-=-=-=-=-=-= 



[Dillo-dev]Email of bug poster in bug reporting engine.

From: DraX  - 2001-09-01 22:51

The email address of the person submittings a bug should be shown in the
bugreporting engine.

I'd like to help the person with bug 200, because i know it's not a dillo
problem, as i use dillo for browsing on openbsd quite a bit :)
", with a missing