- Dillo-dev - lists.mailman3.com

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

Copy and paste from page content area

by obeythepenguin＠gmail.com

On Fri, 07 Jan 2011 07:52:06 -0500, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Hm, I would have thought that copy/paste just works on Windows > via the fltk::copy() call in FltkPlatform::copySelection(). > Does copy/paste work for fltk2/test programs on Windows? > > Cheers, > Johannes Copy/paste works from text boxes with the keyboard shortcuts. Select-and-middle-click works within FLTK (for example, I can copy from the content area to the address bar, no problem), but definitely not to other Windows apps. You'd think it would just work, but when you're dealing with a toolkit as badly broken as FLTK, just about anything is possible -- and don't get me started on X11-isms. I have not tried the test programs, but I will when I have a chance. Fortunately I'm no stranger to patching FLTK. Cheers, ~Benjamin

Jan. 7, 2011

hg repo

by corvid＠lavabit.com

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!

Jan. 7, 2011

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

by Johannes.Hofmann＠gmx.de

Hi, On Tue, Jan 04, 2011 at 12:43:49PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Tue, Jan 04, 2011 at 08:48:05AM +0100, Diego . wrote: > > [...] > > Second. I want to suggest to not to remove the fltk 2.0 support code from dillo. > > > > DilloWidget support more than one "backend" so fltk 1.3 can be added > > whitout remove fltk 2.0 and selected at compile time or even runtime. > > Using 1.3 and compile time as sane defaults, of course. > > Unfortunately this is not true. Dw has an abstraction layer, > but all the user interface is native. I think it wouldn't even make sense to have an abstraction layer for the GUI. The GUI is concentrated in a small number of files in src/* and those files have to be ported. An abstraction layer here would complicate things more than it would help. > > > > A test version that draw 2 windows aech one with a "backend" can ve > > used to compare visual results during the port to 1.3. > > > > To support 2 "backend" now can heltp to support others in the future. > > ?what about a directfb one? Debian instaler will thanks it even i them > > use X now. > > Given the manpower, this *may* be possible. Although I don't > see much worth in supporting a dead library, given the new one is > less buggy and more capable. 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

Jan. 7, 2011

hg repo

by Johannes.Hofmann＠gmx.de

On Mon, Jan 03, 2011 at 05:10:26PM +0000, corvid wrote: > Fredrik wrote: > > On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote: > > > * Can corvid make another repo in the same server? (e.g. for the port > > > to fltk-1.3) > > Isn't it better to just make an other branch in the same repo? Can't everybody > > with commit access do that? That should make bug fix sharing easier, > > right? > > How much does that complicate usage? Is it pretty much 1) name a new branch > and 2) use the same hg commands as usual but add some branch argument? 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. Cheers, Johannes

Jan. 7, 2011