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.