November 2003 - Dillo-dev - lists.mailman3.com

about feedback was: Re: [Dillo-dev] [patch] Cleanup of IO.c

by Andreas Schweitzer

Hi, I post this to the list, so that some other possible future contributor that might get frustrated can find it in the archive :-) > I feel sad and frustrated because of the lack of feedback from the Dillo > developers. I tried to improve Dillo, to add some extra features. Dillo is a > nice browser and I thought that spending my time on it would be appreciated, > but it seems I was wrong. I give up, I'm not going to waste my time on > improving Dillo while all efforts are just ignored or told to be useless > because of the "that mess is fine as it is now" attitude. If the neutral and > obviously (somehow I start doubting that now) improving IO cleanup patch is > ignored, then what chance do I have with cleaning up the CCC horror... I can totally understand you. I, too, sent in patches at times. Not as big as yours, some were useful, some were not. Sometimes, it took quite some time before Jorge looked at the patches and fixed or accepted (or rejected) them. The first time, I was very excited once I submitted the patch. But as time went by and I did not hear anything, I got disappointed, until I finally got feedback - life was good again ;-) ... Anyways, that's how it works here. I got used to it. Also, since Frank and you started contributing great patches, traffic went up quite a bit. I think it's ok, since I skip some threads that I'm not interested in. :-) However, the core developers probably need to read all mails and keep track with a whole lot more patches - therefore, even they may miss one or two patches/suggestions. So, please stay with the project ... hmmm ... some semi-serious suggestion ;-) : do some christmas shopping, enjoy the holidays and wait for the feedback from the developers ...:-) > To give you an idea how bad it is: Unfortunatly I am rather a happy user than a real developer. So, I just read and say "aha" ... Hence, I also could not comment on your cleanup of IO.c > Worst is, making a dpi isn't as simple as making a CGI, as it should be. And > of course the whole dpid construction makes no sense. not really anyway: you > can find all the dpi's the same way as you find the dpid... Sure, dpid has > some minor advantages, but everyhting has _some_ advantages. Currently, I'm just watching the changes to the dpi infrastructure. Sometimes, I too think "hopefully this is not getting too bloated, with two many interfaces". However, overall, I like the dpi idea. There are certain advantages: - For me, it makes it rather easy to contribute, since I need to only write a program and not to dig through dillo's code (if only I did write more than my simplistic finger plugin ;-) ...) - The concept of extra processes instead of extra code has advantages : - with the download plugin being a seperate process you can even log out of X while the download continues (e.g. over night on dial-up). - the bookmark plugin allows for a real bookark server ! This is something I am contemplating about : wouldn't it be cool if you could access the same bookamrks from different machines via a sophisticated bookmark server ? Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 28, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Indan Zupancic

Hi, > I do not understand your disapointing very well and maybe because that i sound rude, excuseme then. Go read Dillo's website, go read the new developer info, go read the files in Dillo's doc dir. Then spend a reasonable amount of time coding for Dillo and cleaning up _their_ mess in IO.c. Then send a patch to the mailing list and wait one week. Let's see if you're disappointed or not. Keep in mind that CVS didn't change the last 6 days, and the last few changes were small, and also don't forget that Jorge claims that he's busy with Dillo full time. Dillo claims to have nice, modular, clean code, and then you encounter some ugly code and try to fix it... I'm afraid I sound rude sometimes too, but we're just telling what we think, right? :) Greetings, Indan

Nov. 27, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Diego Sáenz

In few words: more code and less words. Come on to code it to have something to compare. I will help you if you want and i think that more people in the list will help too. About feedback from developers they are always like that. I think they are busy. I do not understand your disapointing very well and maybe because that i sound rude, excuseme then. Diego. "Indan Zupancic" <indan(a)nul.nu> escribio: > Hello, > > The patch was downloaded 14 times, and zero feedback... Great. I > wanted to cleanup http.c in a similar way, but never mind. > > I feel sad and frustrated because of the lack of feedback from the > Dillo developers. I tried to improve Dillo, to add some extra > features. Dillo is a nice browser and I thought that spending my time > on it would be appreciated, but it seems I was wrong. I give up, I'm > not going to waste my time on improving Dillo while all efforts are > just ignored or told to be useless because of the "that mess is fine > as it is now" attitude. If the neutral and obviously (somehow I start > doubting that now) improving IO cleanup patch is ignored, then what > chance do I have with cleaning up the CCC horror... > > To give you an idea how bad it is: > > There are at least 24 ways of calling a ccc function. That is a > conservative estimation, because I only counted the possible parameter > combinations(values, types), you still need to know which variant of > the many you need to use with a certain module. Also I counted only > the ccc functions of the IO, cache, file, http and dns module, I > didn't count the dpi and capi modules(just didn't come that far). > > This mess means that modules can't communicate transparantly with > eachother, because they need to know exactly which data to give, > implicating that they need to know with which module they're talking. > That makes the whole CCC construction worthless, because one of it > goals, or so I guess, was to have a chain like communication where > linked elements could do their's stuff and notify the next element > without knowing anything specific about eachother. With the current > situation the CCC structure only adds unnecessary complexity to the > overall code, obfuscating it. > > If that's what you want, fine, but then say so, instead of saying that > it's hard to replace. Yes, duh, you made a spaghetti mountain, of > course it's hard to clear that up. I truly hope that the rest of Dillo > is cleaner, and from what I saw of it, the GUI part doesn't look that > bad. > > Next grief: DPI's. > > What was meant like a simple plugin system turned out to become the > sauce over the spaghetti, to stay with the previous metaphor. It seems > like the cache api code handles dpi's differently, at least there is > plenty dpi specific code in the capi.c file, so it seems like it's in > the wrong place. I mean, if it's not part of the cache api, then what > is it doing in that file? capi.c has even it's own CCC function only > for dpi's, so an extra module in a wrapper?? > > Worst is, making a dpi isn't as simple as making a CGI, as it should > be. And of course the whole dpid construction makes no sense. not > really anyway: you can find all the dpi's the same way as you find the > dpid... Sure, dpid has some minor advantages, but everyhting has > _some_ advantages. > > All the dpi code (not including bookmarks.c) is 14K big, just imagine > what you could implement with so much code (native ftp support comes > into mind). Not even talking about how much resources the dpi's use, > because they have such an awkward interface and need to do things that > Dillo already could do, duplicating code and features. > > I'm aware that certain people already wasted too much time on the > current dpi code, so it has zero chance of being changed, I'm not so > naive to think it would. I just give my oppinion on it. I had put my > hope on the IO/CCC mess. > > Sigh, if only Dillo went the GTK2 way, then I could say goodbye > without trouble, but now it seems like Dillo will use FLTK it's even > more depressing. > > --- > > Oh well, enough rambling, if someone wants an updated version of the > installer, then say so. I won't do much with the https patch, because > as it is now it can't be improved much without cleaning up IO, CCC > or/and http, or at least without merging the IOData structures, so > more than synching with CVS and tiny changes won't happen. > > Good luck and take care, > > Indan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 27, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Mike Eriksen

On Thu, 27 Nov 2003, Patrick Shanahan wrote: > * Indan Zupancic <indan(a)nul.nu> [11-27-03 13:42]: > > I'm not qualified to comment about the part snipped... The same goes for me too. > > ------ > > > > Oh well, enough rambling, if someone wants an updated version of the > > installer, then say so. I won't do much with the https patch, because > > as it is now it can't be improved much without cleaning up IO, CCC > > or/and http, or at least without merging the IOData structures, so more > > than synching with CVS and tiny changes won't happen. > > I would appreciate an updated version of the installer. > > Thankyou for your contributions. Please reconsider. I too would very much like an updated installer. And I would be really grateful if you would consider to maintain you HTTPS patch as well. I can understand you are disapointed with the lack of feed back from the official developers, but Dillo *is* a very conservative project. Look at Franks frame/tab patch - it has been around for ages and is still "just" an unofficial patch. I would be sad if you leave Dillo all together. I not only need Dillo+frames+HTTPS for myself, but as you can see from my signature, I'm involved in a linux based thin client project and a light web-mail capable web browser is a killer-app to us! And would make quite an impact on the Dillo user base too. Please reconsider. Mike -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Nov. 27, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Patrick Shanahan

* Indan Zupancic <indan(a)nul.nu> [11-27-03 13:42]: I'm not qualified to comment about the part snipped... > ------ > > Oh well, enough rambling, if someone wants an updated version of the > installer, then say so. I won't do much with the https patch, because > as it is now it can't be improved much without cleaning up IO, CCC > or/and http, or at least without merging the IOData structures, so more > than synching with CVS and tiny changes won't happen. I would appreciate an updated version of the installer. Thankyou for your contributions. Please reconsider. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Nov. 27, 2003

Re: [Dillo-dev] [patch] Cleanup of IO.c

by Indan Zupancic

Hello, The patch was downloaded 14 times, and zero feedback... Great. I wanted to cleanup http.c in a similar way, but never mind. I feel sad and frustrated because of the lack of feedback from the Dillo developers. I tried to improve Dillo, to add some extra features. Dillo is a nice browser and I thought that spending my time on it would be appreciated, but it seems I was wrong. I give up, I'm not going to waste my time on improving Dillo while all efforts are just ignored or told to be useless because of the "that mess is fine as it is now" attitude. If the neutral and obviously (somehow I start doubting that now) improving IO cleanup patch is ignored, then what chance do I have with cleaning up the CCC horror... To give you an idea how bad it is: There are at least 24 ways of calling a ccc function. That is a conservative estimation, because I only counted the possible parameter combinations (values, types), you still need to know which variant of the many you need to use with a certain module. Also I counted only the ccc functions of the IO, cache, file, http and dns module, I didn't count the dpi and capi modules (just didn't come that far). This mess means that modules can't communicate transparantly with eachother, because they need to know exactly which data to give, implicating that they need to know with which module they're talking. That makes the whole CCC construction worthless, because one of it goals, or so I guess, was to have a chain like communication where linked elements could do their's stuff and notify the next element without knowing anything specific about eachother. With the current situation the CCC structure only adds unnecessary complexity to the overall code, obfuscating it. If that's what you want, fine, but then say so, instead of saying that it's hard to replace. Yes, duh, you made a spaghetti mountain, of course it's hard to clear that up. I truly hope that the rest of Dillo is cleaner, and from what I saw of it, the GUI part doesn't look that bad. Next grief: DPI's. What was meant like a simple plugin system turned out to become the sauce over the spaghetti, to stay with the previous metaphor. It seems like the cache api code handles dpi's differently, at least there is plenty dpi specific code in the capi.c file, so it seems like it's in the wrong place. I mean, if it's not part of the cache api, then what is it doing in that file? capi.c has even it's own CCC function only for dpi's, so an extra module in a wrapper?? Worst is, making a dpi isn't as simple as making a CGI, as it should be. And of course the whole dpid construction makes no sense. not really anyway: you can find all the dpi's the same way as you find the dpid... Sure, dpid has some minor advantages, but everyhting has _some_ advantages. All the dpi code (not including bookmarks.c) is 14K big, just imagine what you could implement with so much code (native ftp support comes into mind). Not even talking about how much resources the dpi's use, because they have such an awkward interface and need to do things that Dillo already could do, duplicating code and features. I'm aware that certain people already wasted too much time on the current dpi code, so it has zero chance of being changed, I'm not so naive to think it would. I just give my oppinion on it. I had put my hope on the IO/CCC mess. Sigh, if only Dillo went the GTK2 way, then I could say goodbye without trouble, but now it seems like Dillo will use FLTK it's even more depressing. --- Oh well, enough rambling, if someone wants an updated version of the installer, then say so. I won't do much with the https patch, because as it is now it can't be improved much without cleaning up IO, CCC or/and http, or at least without merging the IOData structures, so more than synching with CVS and tiny changes won't happen. Good luck and take care, Indan

Nov. 27, 2003

Re: [Dillo-dev] patch: toggle force_my_colors

by Paul Pelzl

On Wed, Nov 26, 2003 at 02:06:20PM +0100, Frank de Lange wrote: > >I have attached a pair of Dillo patches. They add a toggle-able menu > >item to the right-button context menu, which enables/disables the > >force_my_colors preference on the fly. I find this useful for some > >occasional websites that Dillo renders rather poorly, as well as sites > >that simply choose a horrid color scheme. > > > >The first patch applies on top of Frank's monster patch v15; the second > >applies against Dillo CVS of 20031119. I hope others find it useful. > > > >Paul > > > > > I can add this to the tab/frame patch if you want, so you don't have to > produce two different versions. I would modify it slightly, so the > option works for all frames (not just the one in which the menu was > popped up). I would also add a DILLO_COMMAND, and I move the menu option > (the content menu is getting to big I think). OK Frank, I'll leave it in your capable hands. :-) Paul

Nov. 26, 2003

Re: [Dillo-dev] patch: toggle force_my_colors

by Frank de Lange

Paul Pelzl wrote: >Hi folks, > >I have attached a pair of Dillo patches. They add a toggle-able menu >item to the right-button context menu, which enables/disables the >force_my_colors preference on the fly. I find this useful for some >occasional websites that Dillo renders rather poorly, as well as sites >that simply choose a horrid color scheme. > >The first patch applies on top of Frank's monster patch v15; the second >applies against Dillo CVS of 20031119. I hope others find it useful. > >Paul > > I can add this to the tab/frame patch if you want, so you don't have to produce two different versions. I would modify it slightly, so the option works for all frames (not just the one in which the menu was popped up). I would also add a DILLO_COMMAND, and I move the menu option (the content menu is getting to big I think). Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 26, 2003

Re: [Dillo-dev] [PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

Indan Zupancic wrote: >Random site that doesn't work (thanks google): >http://www.public.iastate.edu/~stvoh/homepage.html > >"works" with the normal Dillo, but renders nothing with the frames patch >(non-standard frames?). > > <HTML> <HEAD> <TITLE> <FRAMESET ROWS="... etc. Missing title close tag (</TITLE>). In general Dillo does not try its best to render bad HTML, but missing tag problems are so common that I think this should be fixed. I'll have a look at it when I find some time... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 26, 2003

Re: [Dillo-dev] patched dillo via Arch

by Grigory Bakunov

Paul Pelzl wrote: >If anyone on the list is using GNU Arch, you can obtain: > > Dillo CVS > + Frank's tab/frame/kbnav/etc. patch v16 > + Indan's HTTPS patch v2 > + my toggle-force-my-colors patch > >integrated into branch dillo--tabframe-pelzl--16.0 . The archive is: >pelzlpj(a)eecs.umich.edu--2003 ftp://pelzlpj.dyndns.org/pub/paul/tla/2003 > >If you find this useful, please send me a private email. If no one cares, I >won't bother to announce this archive in the future. > > No. Please don't stop! It's very nice idea. For all GNU Arch novices short tutorial how to grab this version from this archive: % tla register-archive pelzlpj(a)eecs.umich.edu--2003 ftp://pelzlpj.dyndns.org/pub/paul/tla/2003 % tla my-default-archive pelzlpj(a)eecs.umich.edu--2003 % tla get dillo--tabframe-pelzl--16.0 After this magical commands you get patched source with all what you need. -- .............................................................. IRC: irc.freenode.net #asplinux Grigory Bakunov ICQ: 51369901 ASPLinux Development Team Life would be so much easier if we could just look at the source code.

Nov. 26, 2003