- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]Frame support in CVS

by Kelson Vibber

At 07:39 PM 2/3/2004, Jacky Lam wrote: > I am new to dillo and I want to use dillo with frame support. I try > dillo in CVS and find it only show some link pages for each frames > respectively. Is it the current status? How about Frank patches? I don't know. I tried applying the latest version of Frank's patch (version 16, from November 24), but ended up with about 30 reject files, so it's clearly *way* out of sync. Unfortunately, Frank hasn't posted here since early December. Does anyone else know what's going on with this? Even if frames aren't being merged in yet, it would be nice to have a patch that's in sync with the new release. Kelson Vibber www.hyperborea.org

Feb. 5, 2004

Re: [Dillo-dev]RPM question, and how close is 0.8.0?

by Kelson Vibber

At 06:14 AM 2/5/2004, Jorge Arellano Cid wrote: >The idea is to have it ready this Sunday so the announcement is >made by Monday in the morning. OK! Sooner than I expected! I may be busy this Sunday evening, but I'll at least build the source RPM and the RH8/RH9/FC1 RPM so they'll be ready on Monday. I'll add anything else I have time for, and do the rest Monday evening. (SuSE 9 will have to wait until Monday since I need to build it at work.) > > 2. Include all DPIs in the dillo package. Do require wget. >... > Just as you, my choice is #2. Sounds good. I'll do that. Kelson Vibber www.hyperborea.org

Feb. 5, 2004

Re: [Dillo-dev]RPM question, and how close is 0.8.0?

by Jorge Arellano Cid

Hi Kelson! On Tue, 3 Feb 2004, Kelson Vibber wrote: > At 08:21 AM 2/3/2004, Jorge Arellano Cid wrote: > > I'll start working on it after the 0.8.0 release. > > Any idea how soon that's coming? The idea is to have it ready this Sunday so the announcement is made by Monday in the morning. The newest CVS has the splash screen (grammar corrections are welcome:), and the pending issues are: * dpis should be able to run from ~/.dillo. I'll check that and maybe provide a shell script to install them there for users not having root access. * pthreads is still linked in dpis. This needs a patch but it's not indispensable. The release will be made with or without it. * Maybe it'd be good to mute dpid when started by dillo (to avoid printing to the terminal, specially when it exits). Not sure though and it's also a minor thing. * Expect reports on portability. This has been done to a good extent so I'll not delay the release because of it. After the release I'll take a week off! :-) > I've started making the necessary changes > for the RPM spec based on the current CVS version. With luck I'll be able > to start building as soon as the tarball is ready. I've posted some test > RPMs at http://www.hyperborea.org/software/dillo/pre.html if anyone's > interested. > > Question: I noticed that several of the included DPIs (https, ftp, > download) require wget. However, the main browser does not require > wget. That leads to several choices as far as RPM dependencies go: > > 1. Include all DPIs in the dillo package. Don't require wget. > 2. Include all DPIs in the dillo package. Do require wget. > 3. Separate the FTP, HTTPS, and download DPIs into a separate package > (something like "dillo-protocols") and set that package to require wget. > > Advantages: > #1: Simple installation, most linux distros probably already include wget > #2: Simple installation, lets you know about wget if you haven't installed > it already. > #3: If you don't want wget, you're not forced to install it. If you want > the plugin, you're told wget is needed. > > Problems: > #1: If you don't have wget, installing won't tell you that you need it. > #2: If you don't want to use those DPIs and you don't want wget, you need > to install it anyway. > #3: Installing is more complicated, because you have to download and > upgrade two RPMs. > > I don't think #1 is really an option, because it means people can install > dillo via RPM and not everything will work. > > I'm inclined to choose #2 over #3, just because of the simplicity. If > someone just wants to install Dillo, they already have to look through a > list of about 10 different RPMs for the right system, and sometimes people > miss the one they need. I occasionally get requests to add an RPM for a > system that's already on the list. On the other hand, some people might > consider wget to be unnecessary if they're not going to be using those DPIs. > > Anyway, has anyone got any thoughts on this issue? Just as you, my choice is #2. Cheers Jorge.-

Feb. 5, 2004

Re: [Dillo-dev]AIX problems

by Jorge Arellano Cid

On Wed, 4 Feb 2004, Riccardo wrote: > Hey Jorge, > > ok, I had to use /bin/sh... > > > > > How? > > > > unpack e clean gtk+-1.2.10 > > cd gtk+-1.2.10 > > copy "fix" to this directory > > chmod +x fix > > find -name "*" -exec ./fix {} \; > > find . -name <etc) > > > > Then grab dillo-0.8.0-pre.Feb02.tar.gz from dillo.org/test/ > > and try it! > > > > can I use CVS too? Yes, but CVS requires to run autogen.sh, which needs a properly intalled autoconf/automake pair. > where do I find this tarball? http://www.dillo.org/test/dillo-0.8.0-pre.Feb02.tar.gz Cheers Jorge.-

Feb. 5, 2004

Re: [Dillo-dev]AIX problems

by Riccardo

Hey Jorge, ok, I had to use /bin/sh... > > How? > > unpack e clean gtk+-1.2.10 > cd gtk+-1.2.10 > copy "fix" to this directory > chmod +x fix > find -name "*" -exec ./fix {} \; find . -name <etc) > Then grab dillo-0.8.0-pre.Feb02.tar.gz from dillo.org/test/ > and try it! > can I use CVS too? where do I find this tarball? -Ric

Feb. 4, 2004

[Dillo-dev]Frame support in CVS

by Jacky Lam

Hi, all, I am new to dillo and I want to use dillo with frame support. I try dillo in CVS and find it only show some link pages for each frames respectively. Is it the current status? How about Frank patches? Thanks. Best regards, Jacky

Feb. 4, 2004

[Dillo-dev]RPM question, and how close is 0.8.0?

by Kelson Vibber

At 08:21 AM 2/3/2004, Jorge Arellano Cid wrote: > I'll start working on it after the 0.8.0 release. Any idea how soon that's coming? I've started making the necessary changes for the RPM spec based on the current CVS version. With luck I'll be able to start building as soon as the tarball is ready. I've posted some test RPMs at http://www.hyperborea.org/software/dillo/pre.html if anyone's interested. Question: I noticed that several of the included DPIs (https, ftp, download) require wget. However, the main browser does not require wget. That leads to several choices as far as RPM dependencies go: 1. Include all DPIs in the dillo package. Don't require wget. 2. Include all DPIs in the dillo package. Do require wget. 3. Separate the FTP, HTTPS, and download DPIs into a separate package (something like "dillo-protocols") and set that package to require wget. Advantages: #1: Simple installation, most linux distros probably already include wget #2: Simple installation, lets you know about wget if you haven't installed it already. #3: If you don't want wget, you're not forced to install it. If you want the plugin, you're told wget is needed. Problems: #1: If you don't have wget, installing won't tell you that you need it. #2: If you don't want to use those DPIs and you don't want wget, you need to install it anyway. #3: Installing is more complicated, because you have to download and upgrade two RPMs. I don't think #1 is really an option, because it means people can install dillo via RPM and not everything will work. I'm inclined to choose #2 over #3, just because of the simplicity. If someone just wants to install Dillo, they already have to look through a list of about 10 different RPMs for the right system, and sometimes people miss the one they need. I occasionally get requests to add an RPM for a system that's already on the list. On the other hand, some people might consider wget to be unnecessary if they're not going to be using those DPIs. Anyway, has anyone got any thoughts on this issue? Kelson Vibber www.hyperborea.org

Feb. 3, 2004

[Dillo-dev]Bookmarks shortcut

by Jorge Arellano Cid

Hi, I was updating the help page for dillo, and when making a keyboard shortcuts table, just realized that Alt-B for bookmarks didn't belong anymore so I replaced it with the much more orthogonal Ctrl-B. Just visit the new help page to see. BTW, is anyone using the alternative ";" for bookmarks? I very seldom use it, but rely heavily on "." and ",". Cheers Jorge.-

Feb. 3, 2004

Re: [Dillo-dev] Re: https dpi

by Jorge Arellano Cid

Hi Madis, On Tue, 27 Jan 2004, Madis Janson wrote: > > On Mon, 3 Nov 2003, Jorge Arellano Cid wrote: > > > On Sat, 25 Oct 2003, Madis Janson wrote: > > > > > Also, there seems to be one process for one connection, which makes hard > > > to implement SSL session cache. > > > > Yes, that happens with dpi filters. The idea in this case is to > > have an http dpi that's able to handle several connections at the > > same time (like the downloads dpi). That is: a dpi server instead > > of a dpi filter. With that scheme session cache is easy to > > implement. > > > > (and BTW much easier for the developer because he can arrange > > things much more freely than when patching inside dillo). > > > > > content-type > > > > (as above). > > > > The https dpi would need to listen the HTTP stream and so has > > access to the content-type sent by the remote https server. > > > > (http://article.gmane.org/gmane.comp.web.dillo.devel/1407) > > if someone would create non-ssl dpi proxy plugin (that just makes > http requests), i will add the ssl part to it (i have working ssl proxy > code, which currently works using a patched dillo). Interesting idea! I'll start working on it after the 0.8.0 release. Cheers Jorge.- PS : Dylan knows crypt stuff. You may work together on it. PS2: He's on dillo-dev.

Feb. 3, 2004

[Dillo-dev]Looking inside the cache

by Jorge Arellano Cid

Hi there! On Mon, 26 Jan 2004, Dylan Dawkins wrote: (it took some days, I'm pushing the next release...) > Its extremely fast and has a small footprint (very important). Yes. I ask because very often, appart from the speed, people mention: stability, simple&easy UI, clean code and that it works OK on low CPU/memory systems. > For my > patch I actually only use the urls that are currently held within the > history list already. So you're trying to find an URL in the cache... > But I can see how that trying to match what's in > the history list to what the user is typing could yield some small loss > of security (if anyone is peeking over the users shoulder). I thought you were to keep an archive with the visited URLs; clearly a privacy problem, but if it only scans what's on memory, it is not much different from what we have now (stack history). > The problem > being solved, is not having to type long urls out all the time. And I > suppose the bookmark idea solves that problem, except when the number of > bookmarks becomes large enough that typing the beginning of your url, is > quicker than looking for the specific bookmark. Looking inside the cache has several interfaces in browsers: * Tabs * Cache list (stack history back/fwd) * History list (full list of the cache) * Predictive URL input * Search dialogs Every one of them have good points and some weaker ones; I assume that's why there're so many mechanisms! :) Given the nature of Dillo, having them all is not a good idea. The point is to find a few that cleanly solve the problem (i.e: enough to solve the problem, and that integrate well with the UI model). I'm not quite sure of what should it be at the moment... For instance, a long time ago we thought with Eric that having a "linear history" menu was a good idea (all the visited URLs sorted by time of visit). That's why we have history.[ch]. It should pop up with the current one highlighted and a right click would make a new popup, this time filtered by the highlighted URL's host (all the visited URLs coming from that host). An interesting idea that has been waiting for a proper implementation. It has the plus of allowing access to the whole list of visited URLs, but may start to get clumsy as the URL list grows. At this point, I believe the best interface is a search dialog: Search cache: In Url : _______ In Title : _______ [Search] [Clear] [Cancel] It can be hooked to a right click menu on the (Web) Search icon. That would also allow to add other search URLs as dictionaries, packages or whatever, configurable from dillorc. One feature of the cache search would be to return the linear history when the input camps are empty. Maybe this interface, plus tabs (or page marks; think of tabs listed in a popup menu) is all we need. > > I wouldn't mind working on the https part of the browser. My skills are > mainly with C++,C embedded coding. I have good experience with the > security > Like SSL tunnels VPN rijndael support in VPN, elliptic curve > cryptography (just a hobby). I am a computer scientist and a Linux > devotee, that started using Linux fulltime from RedHat Linux 6.0. Great. After the release, I'll be preparing the basis of the https dpi server (as requested by Madis) so you both can work on it. By now you can study the downloads server to get the idea of how it all works (of course you'll need to read the dpi docs too). After you get enogh knowledge and are confident enough, you can start working with Madis on https or I can send you a grphical download plugin that needs polishing. > I have not worked with FLTK, but it looks like a good idea. After a testing a prototype GTK2 Dillo, and also after probing the GTK2 version of XFCE, I believe the best path is to abandon GTK2. There's an interesting thread in the list. FLTK would certainly come with a lot of porting work, but I believe there will be enough developers to do it! We're waiting for Sebastian's green light on it to start. He's the main author of Dw, so he's the person that knows best what it would take to port Dw to FLTK. > I have > subscribed already. What specifically is your role in this project? Founder, mantainer, lead developer, webmaster, ... :-) Cheers Jorge.

Feb. 3, 2004