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

Re: [Dillo-dev] HTTPS Patch

by Stephan Goetter

Am Thu, Nov 13, 2003 at 12:23:52PM +0100 schrieb Indan Zupancic und sprach: > > I think something like Arch or Subversion, with an accompanying Wiki for > > developers and users to converse (and converge) is a good idea. > > I'm starting to doubt the whole idea, how nice it may be: Are there any > other active patch makers out there except us? I'm working on JavaScript support for dillo using the SpiderMonkey C-Engine of the Mozilla project: http://www.mozilla.org/js/spidermonkey/ Code as part of the html-file can already be executed. <script>...</script>, window.*(), window.status, location, history, href="javascript:.." do work. The patch is not yet stable/clean enough to post it here and it lacks a lot. Currently I try to clean it up and get the focus set on google. I thought about a patch on top of Frank's patch as I'm using this every day but this wouldn't make things easier. I know most people here have low-end machines and there is probably no interest in JavaScript support in the main branch. Greets, Stephan

Nov. 13, 2003

Re: [Dillo-dev] [RFC] Last call... remove conditional compilation from tab/fram patch?

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [11-13-03 03:25]: > > Those of you who want to keep the conditional compilation options for > tabs and frameset support in the tab/frame patch, speak up now. If I > do not get any serious requests in this direction I will remove the > conditional compilation options in the next patch (any day now...) > and you'll all be stuck with tabs and frames. But... that might be > the reason you applied the patch in the first place, so... Drop the conditional compilation and provide new-window/tab option in the rc file. tks, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Paul Pelzl

On Thu, Nov 13, 2003 at 02:46:56AM +0100, Indan Zupancic wrote: > What about making a seperate Dillo repository, but instead of using CVS > that is too centralized and can't handle branches very well (or so I > heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, > thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much > easier to manage all the patches, with one branch for each "patch" (one > branch for https, one for tab+frames, etc). The hardest part should be to > keep our main branch in sync with Dillo's CVS. The best way to handle that with Arch is to have a "CVS gateway" branch that contains only unmodified CVS sources. Other branches (https, tab/frame, etc.) would be tags ("continuations") of the CVS gateway, which would make it relatively easy to merge in patches from CVS. Of course, the "merge in" is where work is sometimes involved, but I don't know of any general solution to that problem. Paul

Nov. 13, 2003

Re: [Dillo-dev] [RFC] keywords

by Paul Pelzl

On Thu, Nov 13, 2003 at 12:51:06PM +0100, Frank de Lange wrote: > in the location bar, which is interpreted as "search for something or > other" through this keyword definition in the dillorc: > > s:http://www.google.com/search?q= > > You can define as many as these as you want. The format is > > keywords = "<keyword>:<url> <keyword>:<url> ..." I think this is an elegant way to handle it. The most immediate benefit I see is that I can (probably) set up keywords for multiple search sites (teoma, turbo10, alltheweb, etc.). > [ and on the subject of preferences... I know what Havoc et al say, but > I do not always agree... In many cases choice is a good thing, as > long as it is not mandatory to choose. Define sane defaults for those > who can not or do not want to choose, but keep things flexible for > those who want to change those defaults. TIMTOWTDI ] I could not agree more. Paul

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Andreas Schweitzer

On Thu, Nov 13, 2003 at 09:50:29AM +0100, Thorben Thuermer wrote: > On Thu, 13 Nov 2003 07:59:50 +0100 > Frank de Lange <frank(a)unternet.org> wrote: > > Indan Zupancic wrote: > > > > >What about making a seperate Dillo repository, but instead of using CVS > > >that is too centralized and can't handle branches very well (or so I > > >heard), <snip> > erm... or http://auriga.wearlab.de/ ? ;) Or while at it, use indeed the branch mechanism. In the documentation it does not look that much different from current diff-ing. Furthermore, CVS can be configured (with add-ons) to allow certain comittors only comit into certain branches. This is handled via comittinfo and cvs_acls. cvs_acls is a perl script that is at least in the source tar ball of cvs in the contrib section. Most installations of cvs keep it somewhere ( .../share/.../cvs/.../contrib/ ) If ypu should not have a local copy, check http://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in where it is documented in detail how to restrict users to branches. That way, Jorge and Sebastian keep control over the main branch as it is right now, but dedicated branchers could have their repository in the same place. And users simply need to check out these experimental branches. The branchesr only need to marge from current regularly. Of course, I don't know how wearlab has organized their CVS setup and if that would be acceptable. Also, I hope that Jorge or Sebastian read that far down in the thread ;-) ... 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. 13, 2003

Re: [Dillo-dev] [RFC] Last call... remove conditional compilation from tab/fram patch?

by Frank de Lange

Indan Zupancic wrote: > Hello, > > If it will stay a patch always, then you can remove it without problems. I > think you should treat the code as if it is offical, so use only > conditions where you would normally do, otherwise you may need to add them > back later if it's merges with Dillo's code. So the question is, should > Dillo have always tabs and/or frames support? Point is, Sebastian (of Dw fame) has stated that he does not like the conditional compilation options as it complicates code maintenance (which is true). My standpoint was that not everyone liked or needed the extended functionality or (more importantly) could spare the memory for it. I have asked several times on the list whether these options should stay or go, but have not gotten a clear 'stay' response. So, I intend to remove the options since there does not seem to be a need for them. On tab/window preferences, there already is a preference to open new windows in tabs (tab_instead_of_window=YES). I will add an option to ignore the _blank target for those who do not like their browser to open new windows or tabs at random (check the archives for some examples of people complaining about this). 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. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Frank de Lange

Indan Zupancic wrote: >>I think something like Arch or Subversion, with an accompanying Wiki for >>developers and users to converse (and converge) is a good idea. > > > I'm starting to doubt the whole idea, how nice it may be: Are there any > other active patch makers out there except us? If there are, they're hiding in the woodwork. However, this is partly caused by the current way patches are handled. Dillo is not the most patch-friendly project I know of. > If not, then is it worth > all the trouble? For me it's very easy to keep my https patch in sync with > your tabs+frames patch, I'll just sync with CVS when you have a new > version, and then attach your version number to the filename, so that it's > clear which patches are compatible with eachother. Of course doing the > same with other patches won't be as easy, because they may conflict, > something that's unlikely with the https patch and frames+tabs patch. But that means you are dependent on my quirky release schedule... Something you might not like. There can be weeks, but also days between paches. And I do not always keep up to date with the CVS version du jour. But no, I do not know if it is worth the trouble to set up an Arch/Subversion server for this. Unless... > What are the advantages of being a GNU project? Exposure, mindshare. 'Everybody knows GNU'. Continuity of maintenance, sort of. Hosting at Savannah (also open to non-GNU projects). No Arch yet, but that might change... Anyway, it is not ours to decide for Dillo to apply to become a GNU project. Jorge, have you thought about this possibility? 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. 13, 2003

Re: [Dillo-dev] [RFC] external Dillo splash screen

by Indan Zupancic

Hello, No, you misunderstood me Arnold, but that way you also brought new ideas. :) What I meant was that splash_url= or splash_url="" would mean that there is no splash screen at all, while commenting the setting out will give you the default splash screen. This also means it's very easy to get the default back, something both Frank and I overlooked. Show_splash may be more intiutive, but it is so only when it is mentioned in dillorc. One comment above splash_url to tell the user to set it to "" for no splash screen is as easy then. What about a compromis; splash=[NO | url] or something like that? Default is the path to the default splash screen, NO and "" ("" means strlen=0, so splash= is the same) disable it. Also don't forget that whatever option you give, it's much better than the official Dillo that loads it's splash screen ALWAYS, even when you start it with "dillo some_file". Greetings, Indan

Nov. 13, 2003

[RFC] keywords

by Frank de Lange

While we're talking preferences anyway... I have another addition to the range: keywords. In my current version you can type "s something or other" in the location bar, which is interpreted as "search for something or other" through this keyword definition in the dillorc: s:http://www.google.com/search?q= You can define as many as these as you want. The format is keywords = "<keyword>:<url> <keyword>:<url> ..." The end result of a successful keyword match consists of the url for the keyword, followed by an escaped copy of anything that followed the keyword. The above example for "s" looks like this: http://www.google.com/search?q=something%20or%20other This adds next to nothing to the size of Dillo by the way. Any strong sentiments against this functionality? [ and on the subject of preferences... I know what Havoc et al say, but I do not always agree... In many cases choice is a good thing, as long as it is not mandatory to choose. Define sane defaults for those who can not or do not want to choose, but keep things flexible for those who want to change those defaults. TIMTOWTDI ] 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. 13, 2003

Re: [Dillo-dev] [RFC] Last call... remove conditional compilation from tab/fram patch?

by Indan Zupancic

Hello, If it will stay a patch always, then you can remove it without problems. I think you should treat the code as if it is offical, so use only conditions where you would normally do, otherwise you may need to add them back later if it's merges with Dillo's code. So the question is, should Dillo have always tabs and/or frames support? Always frame support makes more sense that always tabs support in my opinion, but just an option in dillorc to enable/disable them is probably enough, both runtime and compile time options may be overkill. The choice should be new windows or new tabs, there is not much more annoying than a new window when the browser supports tabs, the user also can't know if the link will change the current page or pop up a new one. Greetings, Indan

Nov. 13, 2003