Not to name dillo 1.3 & not to drop fltk 2.0 support
Hello and happy new year. I want to suggest something for fltk 1.3 port. First. I think that to name dillo 1.3 vs dillo 2.0 is confusing. Dillo was 2.0 for a lot of changes (css, etc) one of them fltk port. 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. 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. Sorry for my bad english Diego.
Diego wrote:
Hello and happy new year. I want to suggest something for fltk 1.3 port.
First. I think that to name dillo 1.3 vs dillo 2.0 is confusing. Dillo was 2.0 for a lot of changes (css, etc) one of them fltk port.
We don't plan to decrease dillo's version number. Sorry for the confusion there.
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.
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 amount of fltk2 code in src/ now, I have to wonder how well we could support multiple toolkits even in the case when they are all healthy and active...
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.
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. YMMV. -- Cheers Jorge.-
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
On Fri, 07 Jan 2011 08:22:39 -0500, Johannes Hofmann <Johannes.Hofmann@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
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.
On Tue, Jan 04, 2011 at 08:48:05AM +0100, Diego . wrote:
Hello and happy new year. I want to suggest something for fltk 1.3 port.
First. I think that to name dillo 1.3 vs dillo 2.0 is confusing. Dillo was 2.0 for a lot of changes (css, etc) one of them fltk port.
From other posters here and from previously reading the FLTK homepage concerning future versions of FLTK, FLTK is the package downgrading it's version to 1.3 (from 2.0) for the next future release -- not Dillo.
Second. I want to suggest to not to remove the fltk 2.0 support code from dillo.
If you spend some time reading the FLTK homepage, you'll begin to understand why fltk-2.0 is deprecated. fltk-3.0 is the next, hopefully very soon to be released stable version. Gentoo has a fltk-1.3rc ebuild availabe on bugs.gentoo.org. -- Roger http://rogerx.freeshell.org/
On Wed, Jan 05, 2011 at 12:30:22AM +0000, corvid wrote:
Roger wrote:
fltk-3.0 is the next, hopefully very soon to be released stable version.
Is anything still going on with 3.0? It seems like I haven't heard anything about it for some time now...
OOPS! My bag. I meant fltk-1.3 is the next version. (... dumb typos... wish God would make them disappear.) But, while we're on the topic of fltk-3.0 version, from what I read on the fltk website, 3.0 is the future version planned to incorporate 2.0 changes from the earlier 1.0 branch, if they aren't already incorporated to 1.* versions. (I'm no expert on fltk/dillo, just trying to correctly relay what I read.) -- Roger http://rogerx.freeshell.org/
participants (6)
-
corvid＠lavabit.com -
darkspirit5000＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
obeythepenguin＠gmail.com -
rogerx.oss＠gmail.com