diff options
Diffstat (limited to 'old/oldmail/200212.txt')
| -rw-r--r-- | old/oldmail/200212.txt | 769 |
1 files changed, 769 insertions, 0 deletions
diff --git a/old/oldmail/200212.txt b/old/oldmail/200212.txt new file mode 100644 index 0000000..f291e40 --- /dev/null +++ b/old/oldmail/200212.txt @@ -0,0 +1,769 @@ +Re: [Dillo-dev]BR taking extra space and problem with spaces in table + +From: Sebastian Geerken <s.geerken@pi...> - 2002-12-30 10:25 + +A happy outcome is worth waiting for :-) + +On Fri, Jun 28, Pekka Lampila wrote: +> On Tue, 25 Jun 2002 14:13:23 +0200 +> Sebastian Geerken <sgeerken@st...> wrote: +> > In this case, multiple <br>'s would not be rendered properly. A +> > solution may be to examine if this is the first <br> in series (by +> > looking if there are DW_CONTENT_BREAK's before), but for my taste, +> > this is somehow too hackish. (Other opinions?) +> +> It's should work and is certainly better than the current situation. +> So in my opinion, that kind of fix should be committed. + +Since most browsers do so, and it is rather simple, and does not break +anything (AFAIK), I've comitted it. + +Sebastian + + + +[Dillo-dev]*** IMPORTANT *** + +From: Jorge Arellano Cid <jcid@so...> - 2002-12-19 22:35 + +*************************** +* * +* I M P O R T A N T ! * +* * +*************************** + + +Hi there, + +Don't let this pass or you'll miss the boat! + +After thoughtful considerations about our site's facilities, +I've decided to move dillo project to the wearlab in Germany. + +That is: +- web site +- bug track +- downloads +- CVS +- mailing lists + +i.e. everything. + +The good news is that everything is already set and working! + +Well, except for the mailing lists. I lost control of the +current one a long long time ago when James administered it. So, +please go to the new site and SUBSCRIBE YOURSELVES into the new +mailing list (follow the links). + +(You may also want to unsubscribe from the current one.) + +We'll be running from there tomorrow, so please do it now and +report any troubles you may find. + +I've updated several things. Most notably, the project Notes +and the HTML versions for CSS and Dpi. + +The site is: + +http://dillo.auriga.wearlab.de + + +Good luck! +Jorge.- + +PS: Update your bookmarks. + + + +[Dillo-dev]Dillo website statistics + +From: Eduardo Marcel Macan <macan@co...> - 2002-12-19 11:53 + +Hello! The folks that take care of the particular machine where dillo +was hosted just told me that the website stats are up again. + +Cipsga hosts many free software sites and projects, a lot of them +projects from the CIPSGA group themselves. Many of these services=20 +and sites were changing servers due to administrative issues,=20 +that included the dillo website, although they tried to make this=20 +change transparent it seems that some little corners were yet to=20 +be rounded :D + +It is (i think) completely operational now. + +Regards :) + +--=20 +Eduardo Marcel Ma=E7an Gerente de Redes / Network Manager +macan@co... Col=E9gio Bandeirantes + + + +Re: [Dillo-dev]CIPSGA CVS + +From: Eduardo Marcel Macan <macan@co...> - 2002-12-17 19:10 + +Well, it is not *that* difficult, now that my personal life is +kind of stable again, I have root access in some CIPSGA +machines and know who to poke when I don't :) Feel free to mail me +personally, since I do not follow this list daily. + +I'll take a look at it. + +Em Ter, 2002-11-26 =E0s 12:16, Jorge Arellano Cid escreveu: +>=20 +> Hi guys! +>=20 +> The CIPSGA CVS server is running. Just follow the [CVS] link! +>=20 +> I'm also considering to move our mailing list to CIPSGA. BTW +> there're two lists for us already set. The only fact that makes +> me hesitate is that contacting a sysadmin there is hard as hell. +> For instance, our site statistics are down for more than a month, +> and ASFAIK it's a matter of restarting the http server, but +> that requires a sysadmin... +>=20 +> The main gain in moving the mailing list is to get another +> web interface for it (more easily searchable/browseable), and we +> need it. +>=20 +> The other alternative is to wait some meetings I'm having with +> the "Universidad de Chile" to prosper, and set the lists from +> there in a server I can see&touch with my hands! +>=20 +> What do you think of it? +>=20 +>=20 +> Cheers +> Jorge.- +>=20 +>=20 +>=20 +>=20 +> ------------------------------------------------------- +> This S...net email is sponsored by: Get the new Palm Tungsten T +> handheld. Power & Color in a compact size! +> http://ads.so....net/cgi-bin/redirect.pl?palm0002en +> _______________________________________________ +> Dillo-dev mailing list +> Dillo-dev@li... +> https://lists.so....net/lists/listinfo/dillo-dev +>=20 +--=20 +Eduardo Marcel Ma=E7an Gerente de Redes / Network Manager +macan@co... Col=E9gio Bandeirantes + + + +[Dillo-dev]Re: Dillo + +From: Jorge Arellano Cid <jcid@so...> - 2002-12-17 13:37 + +Martin, + + +> Just mailing to say thanks for working on Dillo - it's great :-) +> Recently upgraded to a machine with 256Mb RAM running Debian and was +> rather shocked at quite how much memory Mozilla used - it's pretty but +> I'm not sure that it's worth the memory and dillo runs _much_ faster +> <vbg>. + +Thanks for the recognition! + +IMHO, dillo makes a different browsing experience. It lets you +grab information so quickly, that making quick online research is +possible (you may like to read the project objectives). + + +> Given one of my next tasks is to resurrect a pair of Sun SLCs to +> work as simple web browsers I think Dillo is my only realistic choice. +> One little question (and if I wasn't buried alive under coursework I'd +> try it myself) are you going to support several pages within the same +> window - I found the tabs feature in Opera and then Mozilla really handy +> for fast browsing - is it likely to appear in Dillo? + +Very likely. + +Arvind already has a prototype patch for tabs, and we're +working on the details. We don't want to hurry it, but at least +now you know that somewhere in the world, in a certain machine +dillo has tabs! + +> Keep up the good work :-) + +We are trying as hard as we can. + + +Cheers +Jorge.- + + + +Re: [Dillo-dev]BUG#339 + +From: Melvin Hadasht <melvin.hadasht@fr...> - 2002-12-17 13:34 + +Hi Jorge, + +on Tue, 17 Dec 2002 10:00:27 -0300 (CLST) +Jorge Arellano Cid <jcid@so...> wrote: + +> +> Hi there! +> +> Can anyone reproduce BUG#339? +> +> Jorge.- + + +This bug could *not* be triggered in cvs 0.7.0pre from 14 Dec 2002 +Linux 2.4.19 +gcc 2.95.4 +libc 2.2.5 +gtk 1.2.10 + +Bye + + +-- +Melvin Hadasht + + + +[Dillo-dev]BUG#339 + +From: Jorge Arellano Cid <jcid@so...> - 2002-12-17 13:04 + +Hi there! + +Can anyone reproduce BUG#339? + +Jorge.- + + + +[Dillo-dev]Dillo is great! (fwd) + +From: Jorge Arellano Cid <jcid@so...> - 2002-12-17 13:04 + +---------- Forwarded message ---------- +Date: Mon, 9 Dec 2002 08:03:49 +0100 +From: Michael Mayer <michael-mayer@gm...> +To: jcid@so... +Subject: Dillo is great! + +Hello out there! + +This morning I read a short note about dillo and I'am really enthusiastic +about it. I like compact coding and am really impressed by its speed: Very +good work, thank you! + +I will use it as much as possible and I hope that I will find some time to +have a look inside it. The most important thing I'am missing are more +keyboard shortcuts. But even without this feature: I like it very much. + +Michael + + + +[Dillo-dev]Dillo (fwd) + +From: Jorge Arellano Cid <jcid@so...> - 2002-12-17 13:04 + +---------- Forwarded message ---------- +Date: Thu, 5 Dec 2002 20:23:27 +0000 +From: *** <stu@sp...> +To: jcid@so... +Subject: Dillo + +Hello + +First of all, wow really a neat browser! + +And it works just fine!! I'm using Vector Linux 2.0 +with 16 megs of RAM, and an old Cirrus Logic +video card, and it does just fine! + +I tried Netscape.....I could retire if I had to load more than +one graphic per page (turtle slow), I tried the Lynx Browser +I can do it, but I would have to RElearn how to do stuff, and +I did do it and can if need be. + +However, by chance I came across your website and browser +and just had to give it a try! And it is eXactly what I needed!! + +thanks a bunch!! + +Stu Wilcox +Madisonville, KY + + + +Re: [Dillo-dev]Dillo and MIME types (2) + +From: Lars Clausen <lrclause@cs...> - 2002-12-10 18:13 + +On Tue, 10 Dec 2002, Thomas Heute wrote: +>=20 +> Sorry to bother, +>=20 +> i still didn't fix my problem, what i'd like to do is to be able to click +> on a jar file in Dillo and open an external file with that Jar file as +> parameter. +>=20 +> Or click on a PDF and launch any specified external PDF reader. +>=20 +> Is there actually a way to do that, i don't think PI is my solution. + +I made a patch a while ago that uses the /etc/mailcap file to find +readers. It's not the best way to do it, for several reasons, but it kinda +works. See http://shasta.cs.uiuc.edu/~lrclause/dillo-patchomatic (which is +in severe need of updating). + +Eventually there should be a chooser thing that reads the mailcap file +(lazily) and remembers choices, and the actual handling should prolly be +done via DPI. + +-Lars + +--=20 +Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor +"I do not agree with a word that you say, but I |------------------------= +---- +will defend to the death your right to say it." | Where are we going, and +--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbas= +ket? + + + +[Dillo-dev]Dillo and MIME types (2) + +From: Thomas Heute <thomas.heute@ni...> - 2002-12-10 17:03 + +Sorry to bother, + +i still didn't fix my problem, what i'd like to do is to be able to click on +a jar file in Dillo and open an external file with that Jar file as parameter. + +Or click on a PDF and launch any specified external PDF reader. + +Is there actually a way to do that, i don't think PI is my solution. + +Thanks for your work. + +Thomas. + + + +Re: [Dillo-dev]dpi bookmarks plugin + +From: Ben Woolley <ben@ta...> - 2002-12-08 13:27 + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +Jorge, + +> > I just tried out the dpi1 bookmarks plugin, and I really like the concept. +> +> Thanks! +> +> I've only received a couple of tiny comments that kept me +> somewhat clueless about how it was understood/received. +> +> I know it's not easy to grasp and certainly studying it +> requires some time, but as for your comments, it looks as though +> you've got it right! +> + +It seems like a graceful method, and quite powerful (especially when +listening on tcp). Just for fun, my brother and I wrote a shell script +that used netcat to alter our bookmarks from remote computers (I know, +you already have a solution for that, which is why I didn't bring it up +before) + +By the way, what is your IP? ;) + +> +> > But I started wondering if someone could take advantage of a dpi URL to do +> > something improper. +> > +> > <html> +> > <body> +> > <a href="dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.">test</a> +> > <img src="dpi:/bm/modify?operation=add_url2&title=home2&url=http%3A%2F%2Fhome&submit=submit." alt="test image"> +> > </body> +> > </html> +> > +> > When I load that page, not only does the image alter my bookmarks, when I +> > click on the link the window closes (after altering my bookmarks). This +> > seems to be an issue similar to what is discussed in the HTTP 1.1 spec +> > section 15.1.3. +> +> Yes, I understand the issue. +> + +I knew that you would. I am sure that developing a web browser makes one +familiar with the spec. I just posted the numbers for reference, and +more to prove that _I_ understood the issue. :) + +> > Can POST data be sent instead? Section 9.5 says that POST should be used +> > for "extending a database through an append operation", which is what the +> > plugin actually does. +> > +> > Perhaps the plugin should check for a proper referral from +> > dpi:/bm/modify?operation=add_url&submit=submit. before modifying +> > anything. +> +> Yes, POST could eventually be added... +> + +I actually really like the idea of borrowing the distinction between GET +and POST from HTTP. Web developers are already familiar with it. You could +also have configuration options that restrict dpi executions, but that may +just end up being bloat. + +> > [snip] + +> > +> > Do you already have some sort of plan for this issue? +> +> I recognize that when designing it, I thought that having the +> dpis running locally would cut "in gross" all of those problems. +> +> After reading your email, I kept thinking about it, and two +> ideas remained: +> +> 1.- Only allow a dpi url from dpi-generated pages. +> 2.- Add a dpi command that asks the dpi-server for a key, and +> then use it to acknowledge permissions. +> +> The first is the easiest to implement, it just requires a check +> before allowing the dpi command to be issued. Is not even +> necessary to modify the protocol! (and in the event of a user +> longing to make a custom page, accessed as file, that uses dpi +> url references, it may then be served from an elementary dpi +> program). +> +> The second option is more cumbersome, and requires two actions, +> the key request, and including it in the dpi tag. +> + +#1 had crossed my mind. Perhaps you could specify a standard URL argument +that would tell the plugin that the request was referred from an outside +source, and that the plugin should treat it like a typical GET request and +not do anything special. Dillo would only allow those URLs to execute +plugins from outside. For example: +<a href="dpi:/mb/?submit=outside">Check your Dillo bookmarks</a> + +You could also just limit dpi execution to URLs with _no_ arguments, and +specify that plugins should be written to expect that. + +Anyway, I want to let you know that my brother and I test all of our web +work in Dillo. I use it regularly, even on fast computers. + +Laters, + +Ben Woolley +http://ben.tautology.org +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.2.0 (FreeBSD) + +iD8DBQE980iv88ChLVDxFsIRAgLcAJwNhv+MSnLG2H0dSjM8sP2MHHbqTwCeJoLu +gCpa56QHiw+udAsHUKP4hK4= +=TEj+ +-----END PGP SIGNATURE----- + + + +Re: [Dillo-dev]dpi bookmarks plugin + +From: Jorge Arellano Cid <jcid@so...> - 2002-12-07 13:59 + +Madis, + +> On Fri, 6 Dec 2002, Jorge Arellano Cid wrote: +> +> > I recognize that when designing it, I thought that having the +> > dpis running locally would cut "in gross" all of those problems. +> > +> > After reading your email, I kept thinking about it, and two +> > ideas remained: +> > +> > 1.- Only allow a dpi url from dpi-generated pages. +> > 2.- Add a dpi command that asks the dpi-server for a key, and +> > then use it to acknowledge permissions. +> > +> > The first is the easiest to implement, it just requires a check +> > before allowing the dpi command to be issued. Is not even +> > necessary to modify the protocol! (and in the event of a user +> > longing to make a custom page, accessed as file, that uses dpi +> > url references, it may then be served from an elementary dpi +> > program). +> > +> > The second option is more cumbersome, and requires two actions, +> > the key request, and including it in the dpi tag. +> +> keep it stupid, simple ;) + +BTW, I use Slackware!!! + +> +> As i have understand, there are two types of dpi plugins - +> protocol/mime handler plugins (like ftp://, https://, downloader) and +> "feature" plugins (like bookmarks plugin). The second type uses dpi:// +> protocol in url. Is there any good reason, why links from non-dpi pages +> to dpi:// pages should be allowed? + +The only one I've thought of was described above, and as the +solution is quite simple, I don't see any good reason to allow +links from non-dpi pages to dpi:// urls anymore. + +Does anyone see another reason? + + +Cheers +Jorge.- + + + +Re: [Dillo-dev]dpi bookmarks plugin + +From: madis <madis@cy...> - 2002-12-07 13:01 + +On Fri, 6 Dec 2002, Jorge Arellano Cid wrote: + +> I recognize that when designing it, I thought that having the +> dpis running locally would cut "in gross" all of those problems. +> +> After reading your email, I kept thinking about it, and two +> ideas remained: +> +> 1.- Only allow a dpi url from dpi-generated pages. +> 2.- Add a dpi command that asks the dpi-server for a key, and +> then use it to acknowledge permissions. +> +> The first is the easiest to implement, it just requires a check +> before allowing the dpi command to be issued. Is not even +> necessary to modify the protocol! (and in the event of a user +> longing to make a custom page, accessed as file, that uses dpi +> url references, it may then be served from an elementary dpi +> program). +> +> The second option is more cumbersome, and requires two actions, +> the key request, and including it in the dpi tag. + +keep it stupid, simple ;) + +As i have understand, there are two types of dpi plugins - +protocol/mime handler plugins (like ftp://, https://, downloader) and +"feature" plugins (like bookmarks plugin). The second type uses dpi:// +protocol in url. Is there any good reason, why links from non-dpi pages +to dpi:// pages should be allowed? + +-- +mzz + + + +Re: [Dillo-dev]Dillo on NanoGtk + +From: Richard Tseng <rtseng@em...> - 2002-12-07 07:40 + +Attachments: Message as HTML + +Hi Mabo, +We are developer of NanoGtk. Could you post your dillo port, so that we can +have a look at it ? Great job on porting Dillo to NanoGTK/mips !! +Richard Tseng +Emsoft Limited +http://www.emsoftltd.com +----- Original Message ----- +From: 马波 +To: dillo-dev@li... +Sent: Thursday, November 28, 2002 10:44 AM +Subject: [Dillo-dev]Dillo on NanoGtk + + +Hi, all + +Our team just ported Dillo from x86/X/Gtk+ to mips/NanoX/NanoGtk, +everything went fine except scrolling, that is, when we browse a large page, +we got scrollbars, but once I drag and drop the scrollbar, the page turns +into chaos immediately. However, if I scrolled the page by using PageUP and +PageDown buttons, everything is Ok. +It looks like something goes wrong with the screen refreshment, which +is to say, if you post too many screen-updating request by scrolling the +page with scrollbar, the underlying refresh-request queue handler (NanoGDK?) +just cannot fulfil its responsibilities, while if the request is moderate, +the handler can manage it. +So, based on the observation and my conjecture, I dived into NanoGtk and +tried to resolve this problem: + +1.Scrolling request is sent by gtk_scrolled_window_set_vadjustment +function +2.gtk_scrolled_window_adjustment_changed is the scrolling signal handler, +and it adds the window need to scrolling, scrolled_win, to resize queue by +calling gtk_widget_queue_resize +3.For a Container (Gtkscrolledwindow is a container)，the resizing handler +is gtk_container_clear_resize_widgets +5.BUT, this function just mark the container with GTK_PRIVATE_UNSET_FLAG +(widget, GTK_RESIZE_NEEDED); and do nothing more! + +I was lost!! + +So, I came up with the second solution: Change the +Adjustment->step_increment to Adjustment->page_increment, but it seems +doesn't work also! + +Who can help me! + +mabo + + + + + +------------------------------------------------------- +This S...net email is sponsored by: Get the new Palm Tungsten T +handheld. Power & Color in a compact size! +http://ads.so....net/cgi-bin/redirect.pl?palm0002en +_______________________________________________ +Dillo-dev mailing list +Dillo-dev@li... +https://lists.so....net/lists/listinfo/dillo-dev + + + +[Dillo-dev]Dillo (fwd) + +From: Jorge Arellano Cid <jcid@so...> - 2002-12-06 23:56 + +---------- Forwarded message ---------- +Date: Thu, 5 Dec 2002 20:23:27 +0000 +From: *** <stu@sp...> +To: jcid@so... +Subject: Dillo + +Hello + +First of all, wow really a neat browser! + +And it works just fine!! I'm using Vector Linux 2.0 +with 16 megs of RAM, and an old Cirrus Logic +video card, and it does just fine! + +I tried Netscape.....I could retire if I had to load more than +one graphic per page (turtle slow), I tried the Lynx Browser +I can do it, but I would have to RElearn how to do stuff, and +I did do it and can if need be. + +However, by chance I came across your website and browser +and just had to give it a try! And it is eXactly what I needed!! + +thanks a bunch!! + +Stu Wilcox +Madisonville, KY + + + +Re: [Dillo-dev]dpi bookmarks plugin + +From: Jorge Arellano Cid <jcid@so...> - 2002-12-06 23:56 + +Ben, + +> I just tried out the dpi1 bookmarks plugin, and I really like the concept. + +Thanks! + +I've only received a couple of tiny comments that kept me +somewhat clueless about how it was understood/received. + +I know it's not easy to grasp and certainly studying it +requires some time, but as for your comments, it looks as though +you've got it right! + + +> But I started wondering if someone could take advantage of a dpi URL to do +> something improper. +> +> <html> +> <body> +> <a href="dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.">test</a> +> <img src="dpi:/bm/modify?operation=add_url2&title=home2&url=http%3A%2F%2Fhome&submit=submit." alt="test image"> +> </body> +> </html> +> +> When I load that page, not only does the image alter my bookmarks, when I +> click on the link the window closes (after altering my bookmarks). This +> seems to be an issue similar to what is discussed in the HTTP 1.1 spec +> section 15.1.3. + +Yes, I understand the issue. + +> Can POST data be sent instead? Section 9.5 says that POST should be used +> for "extending a database through an append operation", which is what the +> plugin actually does. +> +> Perhaps the plugin should check for a proper referral from +> dpi:/bm/modify?operation=add_url&submit=submit. before modifying +> anything. + +Yes, POST could eventually be added... + + +> Perhaps change: +> <dpi +> cmd='open_url' +> url='dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.' +> > +> to: +> <dpi +> cmd='open_url' +> url='dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.' +> ref='dpi:/bm/modify?operation=add_url&submit=submit.' +> > +> or: +> <dpi +> cmd='open_url' +> url='dpi:/bm/modify' +> post='operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.' +> > +> or even: +> <dpi +> cmd='open_url' +> url='dpi:/bm/modify' +> ref='dpi:/bm/modify?operation=add_url&submit=submit.' +> post='operation=add_url2&title=home&url=http%3A%2F%2Fhome&submit=submit.' +> > +> +> Do you already have some sort of plan for this issue? + +I recognize that when designing it, I thought that having the +dpis running locally would cut "in gross" all of those problems. + +After reading your email, I kept thinking about it, and two +ideas remained: + +1.- Only allow a dpi url from dpi-generated pages. +2.- Add a dpi command that asks the dpi-server for a key, and +then use it to acknowledge permissions. + +The first is the easiest to implement, it just requires a check +before allowing the dpi command to be issued. Is not even +necessary to modify the protocol! (and in the event of a user +longing to make a custom page, accessed as file, that uses dpi +url references, it may then be served from an elementary dpi +program). + +The second option is more cumbersome, and requires two actions, +the key request, and including it in the dpi tag. + +HTH. + +Cheers +Jorge.- + |