January 2011 - Dillo-dev - lists.mailman3.com

.hgignore

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > +^dpi/[^/]*\.dpi$ > > I get mixed up by the differences in the various regexps out there. > Is this "[^/]" intended as a *looks up the term* bracket expression? > > The hgignore page says it uses Python/Perl syntax, and the first > regexp page that I find ( http://www.greenend.org.uk/rjk/2002/06/regexp.html ) > seems to say that Perl and Python just do character classes when > given brackets. [^...] is a negated class. [^/] matches any charar#cter other than /. If I got it right this matches all *.dpi files in the dpi/ directory. Regards, Jeremy Henty

Jan. 8, 2011

.hgignore

by corvid＠lavabit.com

Jeremy wrote: > +^dpi/[^/]*\.dpi$ I get mixed up by the differences in the various regexps out there. Is this "[^/]" intended as a *looks up the term* bracket expression? The hgignore page says it uses Python/Perl syntax, and the first regexp page that I find ( http://www.greenend.org.uk/rjk/2002/06/regexp.html ) seems to say that Perl and Python just do character classes when given brackets.

Jan. 8, 2011

.hgignore

by onepoint＠starurchin.org

corvid wrote: > These should be in .hgignore, shouldn't they? > > $ hg status > ? dpi/vsource.filter.dpi > ? dpid/dpidc > ? dpid/dpidrc I agree. Suggested patch attached. Regards, Jeremy Henty

Jan. 8, 2011

.hgignore

by corvid＠lavabit.com

These should be in .hgignore, shouldn't they? $ hg status ? dpi/vsource.filter.dpi ? dpid/dpidc ? dpid/dpidrc

Jan. 8, 2011

hg repo

by corvid＠lavabit.com

The downloads DPI is working fairly well now (although I have to resize it before it begins to display anything). It's nice to have something that compiles and runs!

Jan. 8, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by corvid＠lavabit.com

Benjamin wrote: > I understand the arguments for switching, but I'm not convinced the needs > are really all that pressing, or that Dillo can really afford another such > drastic overhaul right now. Well, as I've mentioned, being out of distributions has been really bad for us, http://www.dillo.org/stats/ and becoming totally irrelevant is no good.

Jan. 7, 2011

hg repo

by Johannes.Hofmann＠gmx.de

On Fri, Jan 07, 2011 at 12:45:12PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote: > > Johannes wrote: > > > I would go with a separate repo for fltk-1.3 development. It's still > > > a branch, so we can use 3-way merging to keep things in sync with > > > mainline. The only difference is that you don't get fltk-1.3 > > > development stuff automatically when cloning the main repo - which I > > > think is a good thing. > > > Once it's ready we pull it over in the main repo. That's the same > > > procedure we used for the CSS-experimental branch. > > > > Andreas added a repository for me. > > > > I've done most of the really mindless parts now, so now we > > merely need to do all of the hard parts! > > What are the coordinates of the repo? Check http://hg.dillo.org/ Cheers, Johannes

Jan. 7, 2011

hg repo

by jcid＠dillo.org

On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote: > Johannes wrote: > > I would go with a separate repo for fltk-1.3 development. It's still > > a branch, so we can use 3-way merging to keep things in sync with > > mainline. The only difference is that you don't get fltk-1.3 > > development stuff automatically when cloning the main repo - which I > > think is a good thing. > > Once it's ready we pull it over in the main repo. That's the same > > procedure we used for the CSS-experimental branch. > > Andreas added a repository for me. > > I've done most of the really mindless parts now, so now we > merely need to do all of the hard parts! What are the coordinates of the repo? -- Cheers Jorge.-

Jan. 7, 2011

hg repo

by Johannes.Hofmann＠gmx.de

On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote: > Johannes wrote: > > I would go with a separate repo for fltk-1.3 development. It's still > > a branch, so we can use 3-way merging to keep things in sync with > > mainline. The only difference is that you don't get fltk-1.3 > > development stuff automatically when cloning the main repo - which I > > think is a good thing. > > Once it's ready we pull it over in the main repo. That's the same > > procedure we used for the CSS-experimental branch. > > Andreas added a repository for me. > > I've done most of the really mindless parts now, so now we > merely need to do all of the hard parts! Great. I hope we don't hit any showstoppers...

Jan. 7, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by obeythepenguin＠gmail.com

On Fri, 07 Jan 2011 08:22:39 -0500, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > I would fully move over to fltk-1.3. We still keep the fltk2 code in > the history. > Of course if someone wants to maintain a fltk2 branch, that would be > nice. > > Cheers, > Johannes Maybe I'm in the minority here, but frankly I'd rather see Dillo just pick a toolkit and stick with it. FLTK2 might not have been the best choice in hindsight, but it does the job, and it has a much nicer API than 1.x (I've used both extensively). Porting to another toolkit, even a comparatively trivial port like switching FLTK versions, takes time away from "real" development; makes it difficult for outside developers to participate; and to an outside observer, makes project leadership look somewhat indecisive, especially when we've barely settled in after ditching GTK+ (I'll concede *that* switch was a necessary evil and a vast improvement). I understand the arguments for switching, but I'm not convinced the needs are really all that pressing, or that Dillo can really afford another such drastic overhaul right now. Cheers, ~Benjamin

Jan. 7, 2011