September 2008 - Dillo-dev - lists.mailman3.com

Who among you values standard_widget_colors? (was Re: [Dillo-dev] cut off word ends with italic fonts)

by Johannes.Hofmann＠gmx.de

On Tue, Sep 23, 2008 at 09:17:28PM +0000, corvid wrote: > Jorge encouraged me to add that preference in case anyone wanted it > back when the, ahh, 'nonstandard' widget colors came along some months ago, > but I have no idea whether anyone uses it. I'm running with standard_widget_colors=NO all the time and like it. Cheers, Johannes

Sept. 24, 2008

patch: Re: [Dillo-dev] release packaging

by jcid＠dillo.org

On Wed, Sep 24, 2008 at 06:09:44AM +0000, corvid wrote: > bf wrote: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-toolkits/fltk2/ > > > > (but unfortunately you won't be able to view that with dillo2: > > "HTTP warning: Content-Type 'text/html' doesn't match the real data." -- fixes?) > > "gzip" has been registered with the IANA since...since trilobites stalked > the seas, and I explicitly said "gzip" for Accept-Encoding, not "x-gzip", > but rfc2616 does state: > For compatibility with previous implementations of HTTP, > applications SHOULD consider "x-gzip" and "x-compress" to be > equivalent to "gzip" and "compress" respectively. > Committed. -- Cheers Jorge.-

Sept. 24, 2008

patch: Re: [Dillo-dev] release packaging

by corvid＠lavabit.com

bf wrote: > http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-toolkits/fltk2/ > > (but unfortunately you won't be able to view that with dillo2: > "HTTP warning: Content-Type 'text/html' doesn't match the real data." -- fixes?) "gzip" has been registered with the IANA since...since trilobites stalked the seas, and I explicitly said "gzip" for Accept-Encoding, not "x-gzip", but rfc2616 does state: For compatibility with previous implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.

Sept. 24, 2008

release packaging

by corvid＠lavabit.com

Jorge wrote: > On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote: > > On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote: > > > > > Currently you need to download three tarballs to compile dillo > > > (fltk,dw,dillo). I doubt that any linux distribution has fltk2 > > > packages at the moment. (and also not openembedded) What's the plan > > > about that? > > > > FLTK2's API is still not frozen, and its ABI does change quite often > > so we will have to supply the tarball ourselves. It would be simplest > > just to keep a copy of the right FLTK2 snapshot on the dillo site > > under a link saying "use *this* version". The problem is not that > > distros won't supply packages, the problem is that they *will* and it > > might be the wrong version. (Expect "I upgraded FLTK2 and Dillo > > crashed" reports!) > > > > The dw package is an awkward case. I think we should bite the bullet > > and either move it inside dillo2 or make it an independent package > > that the user installs and have dillo2 find and use the installed dw > > (and lose the dw-testbed symbolic link). > > > > Thoughts? > > I'd move dw2 inside dillo2's tree (as it was before), > and have a recommended FLTK2 tarball in our site. > > Please somebody send me a patch with this code move. > That way I can focus on Tabs... I will.

Sept. 24, 2008

release packaging

by jcid＠dillo.org

On Tue, Sep 23, 2008 at 04:15:01PM +0200, Christian Kellermann wrote: > * Jeremy Henty <onepoint(a)starurchin.org> [080923 15:57]: > > On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote: > > > > The dw package is an awkward case. I think we should bite the bullet > > and either move it inside dillo2 or make it an independent package > > that the user installs and have dillo2 find and use the installed dw > > (and lose the dw-testbed symbolic link). > > > > Sorry for this interruption but what is the reason dw exists? > I never understood that. Dw2 can also be used for other projects. Sometime ago, having independent trees allowed Sebastian and me to work comfortably. but now, AFAIS, dw2 fits better inside dillo2's tree. -- Cheers Jorge.-

Sept. 24, 2008

release packaging

by jcid＠dillo.org

On Tue, Sep 23, 2008 at 02:54:10PM +0100, Jeremy Henty wrote: > On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote: > > > Currently you need to download three tarballs to compile dillo > > (fltk,dw,dillo). I doubt that any linux distribution has fltk2 > > packages at the moment. (and also not openembedded) What's the plan > > about that? > > FLTK2's API is still not frozen, and its ABI does change quite often > so we will have to supply the tarball ourselves. It would be simplest > just to keep a copy of the right FLTK2 snapshot on the dillo site > under a link saying "use *this* version". The problem is not that > distros won't supply packages, the problem is that they *will* and it > might be the wrong version. (Expect "I upgraded FLTK2 and Dillo > crashed" reports!) > > The dw package is an awkward case. I think we should bite the bullet > and either move it inside dillo2 or make it an independent package > that the user installs and have dillo2 find and use the installed dw > (and lose the dw-testbed symbolic link). > > Thoughts? I'd move dw2 inside dillo2's tree (as it was before), and have a recommended FLTK2 tarball in our site. Please somebody send me a patch with this code move. That way I can focus on Tabs... -- Cheers Jorge.-

Sept. 24, 2008

Who among you values standard_widget_colors? (was Re: [Dillo-dev] cut off word ends with italic fonts)

by corvid＠lavabit.com

Jorge encouraged me to add that preference in case anyone wanted it back when the, ahh, 'nonstandard' widget colors came along some months ago, but I have no idea whether anyone uses it.

Sept. 23, 2008

Redraw storms

by onepoint＠starurchin.org

Replying to myself: > On Tue, Sep 23, 2008 at 04:03:17PM +0200, Johannes Hofmann wrote: > > > Switching to ShrinkTabPager solves the problem for me (see patch). > > Yes, this also works for the fltk2 tabs example, just add > > fltk::TabGroup::default_pager (fltk::PAGER_SHRINK); > > But, <sigh>, it's also buggy. If you hack the fltk2 tabs example as > above, select tab4 and narrow the window then the text of "very long > tab text" appears at the other side of tab4 and obscures tab3! I'm sorry for being so negative. Thanks, Johannes, for confirming that it's a FLTK bug and finding a workaround. I would prefer the default pager if it worked because it gives a list of all tabs, but at the moment this bug makes the shrink pager far better. > Time for a visit to the FLTK bug tracker. I've raised reports for the redraw storm and tab text display issues: http://www.fltk.org/str.php?L2047 http://www.fltk.org/str.php?L2048 Regards, Jeremy Henty

Sept. 23, 2008

Redraw storms

by onepoint＠starurchin.org

On Tue, Sep 23, 2008 at 04:03:17PM +0200, Johannes Hofmann wrote: > Yes, I can reproduce it with the tabs example from the fltk2 tarball > (after adding an w->clear_double_buffer() to see the redraws). Confirmed. > It seems to be related to the MenuTabPager that is used by default. > Switching to ShrinkTabPager solves the problem for me (see patch). Yes, this also works for the fltk2 tabs example, just add fltk::TabGroup::default_pager (fltk::PAGER_SHRINK); But, <sigh>, it's also buggy. If you hack the fltk2 tabs example as above, select tab4 and narrow the window then the text of "very long tab text" appears at the other side of tab4 and obscures tab3! Time for a visit to the FLTK bug tracker. Regards, Jeremy Henty

Sept. 23, 2008

Redraw storms

by onepoint＠starurchin.org

On Tue, Sep 23, 2008 at 03:12:46PM +0000, corvid wrote: > I begin to wonder how long it'll be before we end up on fltk 1.3. Me too. It seems to me that FLTK-2 is not stabilising within any reasonable time and the developers are now giving most of their effort to FLTK-1.3. (They're even devoting lots of time to <gasp> the documentation!!!) Does/will FLTK-1.3 have tabs? Regards, Jeremy Henty

Sept. 23, 2008