- Dillo-dev - lists.mailman3.com

Valgrind errors from downloads.cc

by onepoint＠starurchin.org

Valgrind is reporting uninitialised data in DLItem::update() in downloads.cc[1]. Here's the code with the offending lines (705, 706) marked. /* Rate */ if (csec >= 2) { tsec = (float) (curr_time - twosec_time); ! rate = ((float)(curr_bytesize-twosec_bytesize) / 1024) / tsec; ! snprintf(str, 64, (rate < 100) ? "%.1fK/s" : "%.0fK/s", rate); prRate->copy_label(str); prRate->redraw_label(); } I'm wondering what is happening here. DLItem::update() is scheduled to be run every second. I think that twosec_time is only set to an initialised value when the function has been run at least twice before. Also, csec is calculated from the difference between the current time and the initial time. Is it possible that the "csec >= 2" could be true even when the function has been run only once before? After all, the timing of callbacks is never exact. Perhaps the callback should explicitly count how many times it has been called rather than attempt to work it out from the timing? Regards, Jeremy Henty [1] http://starurchin.org/dillo/valgrind.html http://starurchin.org/dillo/valgrind/6444c6ff40e01e517ce6e802f23670c5422c6e… http://starurchin.org/dillo/valgrind/68bd8732669bbac8e11f1ea5a692db022fc6a6… http://starurchin.org/dillo/valgrind/6f1d6a4feadf8136cbed37497a1d6dbbfea4a3… http://starurchin.org/dillo/valgrind/68026e750cc92b08699c26392ecfd92cf370a9…

Feb. 7, 2011

for 1.3 port, latest fltk snapshot is required

by corvid＠lavabit.com

..because we're using some new stuff that they added for us http://fltk.org/newsgroups.php?s23204+gfltk.general+v23210+T0

Feb. 4, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by rogerx.oss＠gmail.com

Anybody else notice the mouse wheel is slow within Dillo? Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower compared to Seamonkey. Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. -- Roger http://rogerx.freeshell.org/

Feb. 4, 2011

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

> On Thu, Feb 03, 2011 at 05:49:45AM +0000, corvid wrote: >I'm not too clear on what you might be seeing, but I just pushed >a change that fixes _my_ main problem with the scrollbars, and >maybe they're the same thing. > >There's still the issue that we send events to the scrollbars >when they're hidden. We could check visible(), but perhaps >Johannes would prefer to do some more battle with the resizing >instead. Yup. Bingo! Your latest commit fixed the scrollbar stagger/stall! -- Roger http://rogerx.freeshell.org/

Feb. 4, 2011

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

oh, btw, there appears to be no CPU/Memory excessive usage either. It just happens as if the code is missing a refresh cycle or waiting on something to return? > On Thu, Feb 03, 2011 at 05:49:45AM +0000, corvid wrote: >I'm not too clear on what you might be seeing, but I just pushed >a change that fixes _my_ main problem with the scrollbars, and >maybe they're the same thing. > >There's still the issue that we send events to the scrollbars >when they're hidden. We could check visible(), but perhaps >Johannes would prefer to do some more battle with the resizing >instead. > > >_______________________________________________ >Dillo-dev mailing list >Dillo-dev(a)dillo.org >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2011

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

When using the scrollbar to scroll, the scrollbar & page will stop scrolling even though you are still trying to use the scrollbar to move up or down. However, if you use pgdown/pgup... are just click on the bottom or top of the scrollbar, scrolling will proceed page by page without stopping. This bug occurs when the user tries to smooth scroll the page up or down and ceases to exist when moving up or down by page height. I pulled this git yesterday. I'll re-pull/upgrade today sometime. > On Thu, Feb 03, 2011 at 05:49:45AM +0000, corvid wrote: >I'm not too clear on what you might be seeing, but I just pushed >a change that fixes _my_ main problem with the scrollbars, and >maybe they're the same thing. > >There's still the issue that we send events to the scrollbars >when they're hidden. We could check visible(), but perhaps >Johannes would prefer to do some more battle with the resizing >instead. > > >_______________________________________________ >Dillo-dev mailing list >Dillo-dev(a)dillo.org >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2011

dillo fltk-1.3 scroll bar delay

by johannes.hofmann＠gmx.de

On Thu, Feb 03, 2011 at 01:53:03AM +0000, Roger wrote: > > I messed around with ltrace to debug the scrollbar delay within dillo fltk-1.3 > port. Here's what I get so far. Can you please explain the exact issue you are seeing? Is scrolling generally slow (also with PageDown or drag scrolling), or is it just scrollbar related? For me scrolling is pretty snappy since quite some time now. Cheers, Johannes

Feb. 3, 2011

dillo fltk-1.3 scroll bar delay

by corvid＠lavabit.com

I'm not too clear on what you might be seeing, but I just pushed a change that fixes _my_ main problem with the scrollbars, and maybe they're the same thing. There's still the issue that we send events to the scrollbars when they're hidden. We could check visible(), but perhaps Johannes would prefer to do some more battle with the resizing instead.

Feb. 3, 2011

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

I messed around with ltrace to debug the scrollbar delay within dillo fltk-1.3 port. Here's what I get so far. roger@localhost1 ~ $ ltrace -c -p 11442 % time seconds usecs/call calls function ------ ----------- ----------- --------- -------------------- 18.32 0.291790 6785 43 _ZN8Fl_Group4drawEv 11.69 0.186144 1861 100 _ZN7Fl_Tabs6handleEi 9.70 0.154394 8126 19 _ZN9Fl_Window5flushEv 9.41 0.149853 7887 19 _ZN9Fl_Window4drawEv 9.05 0.144073 7582 19 _ZN7Fl_Tabs4drawEv 8.98 0.142919 793 180 _ZN8Fl_Group6handleEi 6.62 0.105367 115 911 _Znwj 5.82 0.092602 101 911 _ZdlPv 4.82 0.076755 102 746 _ZN2Fl12event_insideEPK9Fl_Widget 2.34 0.037301 153 243 strlen 2.11 0.033615 107 314 malloc 2.06 0.032840 104 314 free 1.81 0.028844 1696 17 _Z9fl_scrolliiiiiiPFvPviiiiES_ 1.49 0.023788 141 168 _ZdaPv 1.11 0.017654 105 168 _Znaj 1.04 0.016517 105 157 __vsnprintf_chk 1.01 0.016079 102 157 _ZN9Fl_Input_5valueEPKc 0.89 0.014229 459 31 _ZN8Fl_Input6handleEi 0.39 0.006271 169 37 _ZNK8Fl_Group10draw_childER9Fl_Widget 0.34 0.005480 103 53 _ZNK8Fl_Group5arrayEv 0.31 0.004997 138 36 _ZNK8Fl_Group12update_childER9Fl_Widget 0.23 0.003682 108 34 _ZN9Fl_Slider11scrollvalueEiiii 0.16 0.002508 192 13 _ZN9Fl_Button4drawEv 0.12 0.001868 116 16 _ZN9Fl_Button6handleEi 0.11 0.001818 106 17 _ZN9Fl_Widget6damageEh 0.02 0.000380 190 2 _ZN6Fl_Box4drawEv 0.02 0.000361 180 2 _ZN8Fl_Input4drawEv 0.01 0.000227 113 2 _ZN9Fl_Window6resizeEiiii ------ ----------- ----------- --------- -------------------- 100.00 1.592356 4729 total roger@localhost1 ~ $ ltrace -c -p 11442 % time seconds usecs/call calls function ------ ----------- ----------- --------- -------------------- 29.26 29.729943 120364 247 _ZN8Fl_Group4drawEv 14.75 14.984334 149843 100 _ZN9Fl_Window5flushEv 14.72 14.952232 149522 100 _ZN9Fl_Window4drawEv 14.69 14.922999 149229 100 _ZN7Fl_Tabs4drawEv 13.48 13.693784 228229 60 _Z9fl_scrolliiiiiiPFvPviiiiES_ 4.09 4.157141 329 12601 strlen 2.28 2.320390 860 2695 _Znwj 2.28 2.317818 860 2695 _ZdlPv 2.15 2.186969 1436 1522 free 0.41 0.421299 141 2982 _ZNK8Fl_Group5arrayEv 0.23 0.238538 126 1884 _ZN2Fl12event_insideEPK9Fl_Widget 0.22 0.220701 147 1500 _ZNK8Fl_Group12update_childER9Fl_Widget 0.19 0.188841 2121 89 _ZN7Fl_Tabs6handleEi 0.18 0.179153 248 720 _ZN8Fl_Group6resizeEiiii 0.18 0.179127 117 1522 malloc 0.16 0.159278 556 286 _ZNK8Fl_Group10draw_childER9Fl_Widget 0.13 0.128988 503 256 _ZN8Fl_Group6handleEi 0.09 0.094990 124 761 __vsnprintf_chk 0.09 0.089326 117 761 _ZN9Fl_Input_5valueEPKc 0.08 0.082873 2762 30 _Z9fl_cursor9Fl_Cursorjj 0.08 0.078284 130 600 _ZN9Fl_Input_6resizeEiiii 0.05 0.048376 115 420 _ZN9Fl_Widget6resizeEiiii 0.04 0.042491 118 360 _Z8fl_widthPKci 0.04 0.036692 136 269 _Znaj 0.03 0.030249 112 269 _ZdaPv 0.02 0.024592 105 233 fl_utf8fwd 0.01 0.013969 194 72 _ZN8Fl_Input4drawEv 0.01 0.013501 112 120 _ZN9Fl_Slider11scrollvalueEiiii 0.01 0.012305 146 84 _ZN8Fl_Input6handleEi 0.01 0.012155 289 42 _ZNK9Fl_Widget10draw_labelEv 0.01 0.007515 121 62 fl_utf8back 0.01 0.007343 174 42 _ZNK9Fl_Widget13draw_backdropEv 0.01 0.006733 112 60 _ZN9Fl_Widget6damageEh 0.00 0.004839 115 42 _ZNK9Fl_Widget8draw_boxE10Fl_Boxtypej 0.00 0.002366 182 13 _ZN9Fl_Button4drawEv 0.00 0.001462 104 14 _ZN6Fl_Box6handleEi 0.00 0.001444 103 14 _ZN9Fl_Button6handleEi 0.00 0.000528 264 2 _ZN6Fl_Box4drawEv 0.00 0.000226 113 2 _ZN9Fl_Window6resizeEiiii ------ ----------- ----------- --------- -------------------- 100.00 101.593794 33631 total

Feb. 3, 2011

Yong Li added you as a business connection on Plaxo

by rogerx.oss＠gmail.com

> On Tue, Feb 01, 2011 at 11:08:29PM -0800, Li Yong wrote: > > Yong Li wants to add you as a business connection on Plaxo. > > To accept this connection request, go to: > [1]http://www.plaxo.com/invite?lang=en&i=120351393&k=1829487072&l=en > > Thanks, > The Plaxo team I feel all cuddly and specially sweet now. ... for a while, thought I might need to go roll myself in powdered sugar. -- Roger http://rogerx.freeshell.org/

Feb. 2, 2011

Yong Li added you as a business connection on Plaxo

by plaxo＠mx.plaxo.com

Yong Li wants to add you as a business connection on Plaxo. To accept this connection request, go to: http://www.plaxo.com/invite?lang=en&i=120351393&k=1829487072&l=en&src=email… Thanks, The Plaxo team Plaxo - your address book for life. Don't want to receive emails from Plaxo any more? Go to: http://www.plaxo.com/stop?src=email&et=1&est=business&etv=jun10d&el=en&emai… Plaxo, Inc. - 203 Ravendale Drive - Mountain View - CA - 94043 - USA

Feb. 2, 2011

patch: configure rm libpng version tests

by weigelt＠metux.de

* Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > No, upstream should do that (packagers should not have to touch any > > area of the sourcecode). And importing packages should _use_ it. > > (instead of old legacy cruft like the -config scripts or esoteric > > autofool macros). > > You are misunderstanding what I say. Packagers should depend on > pkg-config. If they don't, they are responsible for doing it by hand. To make it a bit more clear: packagers (those folks who create the packages for certain distros) should (be able to) rely on the individual upstreams properly using the pkg-config infrastructure, so they have one common place for doing their necessary adaptions. > > Why should some refuse to install such an fundamental tool ? > > Have you ever looked at the pkg-config source? For something as > fundamental as pkg-config, the source code is a mess. It has a local > copy of at least half of glib1 for example... Yes, I've worked on the codebase. It's not nice, but at least it works (probably better than it will after the already discussed transition to glib2 ;-p). Patches are always welcomed ;-) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

Jan. 31, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Mon, Jan 31, 2011 at 01:21:36AM +0100, Enrico Weigelt wrote: > * Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote: > > > * Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > > > Pretty much. If you don't have it, you can still override the automatic > > > > detection via PNG_CFLAGS / PNG_LIBS or so. > > > > > > Which requires another special tweak in the distro's package > > > build rules/descriptors - exactly what packagers do not like. > > > > Packagers should provide pkg-config. > > No, upstream should do that (packagers should not have to touch any > area of the sourcecode). And importing packages should _use_ it. > (instead of old legacy cruft like the -config scripts or esoteric > autofool macros). You are misunderstanding what I say. Packagers should depend on pkg-config. If they don't, they are responsible for doing it by hand. > > The only situation in which the manual override is needed if you > > want to build it on a system that doesn't have pkg-config and > > where you don't want to install it. > > Why should some refuse to install such an fundamental tool ? Have you ever looked at the pkg-config source? For something as fundamental as pkg-config, the source code is a mess. It has a local copy of at least half of glib1 for example... Joerg

Jan. 31, 2011

patch: configure rm libpng version tests

by weigelt＠metux.de

* Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote: > > * Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > > > > Because most of the original libpng-config is older than the pkgconfig > > > support in libpng :) > > > > Be prepared that it gets dropped some day. (some distros maybe > > already removed it already). And keep in mind that these *-config > > scripts are quite crosscompile-unfriedly. > > Well, as long as upstream installs it... Lets see, how long ... > > > Pretty much. If you don't have it, you can still override the automatic > > > detection via PNG_CFLAGS / PNG_LIBS or so. > > > > Which requires another special tweak in the distro's package > > build rules/descriptors - exactly what packagers do not like. > > Packagers should provide pkg-config. No, upstream should do that (packagers should not have to touch any area of the sourcecode). And importing packages should _use_ it. (instead of old legacy cruft like the -config scripts or esoteric autofool macros). > The only situation in which the manual override is needed if you > want to build it on a system that doesn't have pkg-config and > where you don't want to install it. Why should some refuse to install such an fundamental tool ? cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

Jan. 31, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote: > * Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > > Because most of the original libpng-config is older than the pkgconfig > > support in libpng :) > > Be prepared that it gets dropped some day. (some distros maybe > already removed it already). And keep in mind that these *-config > scripts are quite crosscompile-unfriedly. Well, as long as upstream installs it... > > > Pretty much. If you don't have it, you can still override the automatic > > detection via PNG_CFLAGS / PNG_LIBS or so. > > Which requires another special tweak in the distro's package > build rules/descriptors - exactly what packagers do not like. Packagers should provide pkg-config. The only situation in which the manual override is needed if you want to build it on a system that doesn't have pkg-config and where you don't want to install it. Joerg

Jan. 30, 2011

patch: configure rm libpng version tests

by weigelt＠metux.de

* Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > Because most of the original libpng-config is older than the pkgconfig > support in libpng :) Be prepared that it gets dropped some day. (some distros maybe already removed it already). And keep in mind that these *-config scripts are quite crosscompile-unfriedly. > Pretty much. If you don't have it, you can still override the automatic > detection via PNG_CFLAGS / PNG_LIBS or so. Which requires another special tweak in the distro's package build rules/descriptors - exactly what packagers do not like. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

Jan. 30, 2011

Final release of FLTK 2.0 Dillo

by jcid＠dillo.org

On Sat, Jan 29, 2011 at 08:57:33PM +0000, corvid wrote: > T wrote: > > I wonder what a projected timeline for the 1.3 release will be.... No timeline yet (we'd need some effort estimation for it) > I suppose a safe answer is a) when it's ready, and b) the value will be a > function of the degree of community involvement. > > How many things are even still decently broken? Let's see... > - the UI needs attention > - the user/pass dialog, and choice5 dialog > - a couple of scrollbar infelicities > - complexButton drawing > - some event focus stuff that we haven't untangled yet. Using this as an "effort estimation", I'd say if one developer works full time one week on it, most of it would be done. No big deal. (FWIW, I wrote dillo's GTK1 and FLTK2 UI). BTW, the key point in dillo development since a long time, is manpower. When there're developers working on something, it advances very well. For the same reason, I want to thank corvid for all the effort he has put on the 1.3 branch. When I have some time I'll look into the UI. -- Cheers Jorge.-

Jan. 30, 2011

Final release of FLTK 2.0 Dillo

by rogerx.oss＠gmail.com

> On Sat, Jan 29, 2011 at 06:42:00PM -0500, Benjamin Johnson wrote: >On Sat, 29 Jan 2011 18:26:32 -0500, Roger <rogerx.oss(a)gmail.com> wrote: > >> ??? But all the other browsers are bloating pieces of cr*p though! > >Yes, Lynx is really letting itself go these days... Sorry. Forgot my other most used browser, aside from Dillo, is ELinks. Guess I was really poking at the other GUI browsers! -- Roger http://rogerx.freeshell.org/

Jan. 30, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Sat, Jan 29, 2011 at 08:38:50PM +0000, corvid wrote: > Enrico wrote: > > * corvid <corvid(a)lavabit.com> schrieb: > > > + PNG_CONFIG=`which libpng-config` > > > fi > > > > Why not just using pkg-config ? > > (which would be _much_ more distmaintainer/packager-friendly) Because most of the original libpng-config is older than the pkgconfig support in libpng :) > > > > PKG_CHECK_MODULE([...]) > > Is pkg-config ubiquitous where we aren't adding to dependencies too much? Pretty much. If you don't have it, you can still override the automatic detection via PNG_CFLAGS / PNG_LIBS or so. Joerg

Jan. 30, 2011

Final release of FLTK 2.0 Dillo

by obeythepenguin＠gmail.com

On Sat, 29 Jan 2011 18:26:32 -0500, Roger <rogerx.oss(a)gmail.com> wrote: > ??? But all the other browsers are bloating pieces of cr*p though! Yes, Lynx is really letting itself go these days...

Jan. 30, 2011

Final release of FLTK 2.0 Dillo

by rogerx.oss＠gmail.com

> On Sat, Jan 29, 2011 at 08:57:33PM +0000, corvid wrote: >T wrote: >> I wonder what a projected timeline for the 1.3 release will be.... > >I suppose a safe answer is a) when it's ready, and b) the value will be a >function of the degree of community involvement. >How many things are even still decently broken? Let's see... >- the UI needs attention >- the user/pass dialog, and choice5 dialog >- a couple of scrollbar infelicities >- complexButton drawing >- some event focus stuff that we haven't untangled yet. I see the glitch or two within the UI, along with scrollbar lag. >I'm not sure that I even have any need for ordinary dillo anymore. >I still run it by accident sometimes, but... ??? But all the other browsers are bloating pieces of cr*p though! What's even funnier, I think the major news websites just tripled the amount of scripts on their websites within the past month! Pretty soon, we're going to need a 2Ghz CPU just to Google! -- Roger http://rogerx.freeshell.org/

Jan. 30, 2011

Final release of FLTK 2.0 Dillo

by corvid＠lavabit.com

T wrote: > I wonder what a projected timeline for the 1.3 release will be.... I suppose a safe answer is a) when it's ready, and b) the value will be a function of the degree of community involvement. How many things are even still decently broken? Let's see... - the UI needs attention - the user/pass dialog, and choice5 dialog - a couple of scrollbar infelicities - complexButton drawing - some event focus stuff that we haven't untangled yet. I'm not sure that I even have any need for ordinary dillo anymore. I still run it by accident sometimes, but...

Jan. 29, 2011

patch: configure rm libpng version tests

by corvid＠lavabit.com

Enrico wrote: > * corvid <corvid(a)lavabit.com> schrieb: > > + PNG_CONFIG=`which libpng-config` > > fi > > Why not just using pkg-config ? > (which would be _much_ more distmaintainer/packager-friendly) > > PKG_CHECK_MODULE([...]) Is pkg-config ubiquitous where we aren't adding to dependencies too much? I guess I like to imagine dillo in the hands of someone like me who is not a maintainer/packager and might have weird/old/underpowered hardware and have limited patience for finding/downloading/compiling even more stuff in order to find out whether I even like dillo.

Jan. 29, 2011

patch: configure rm libpng version tests

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > + PNG_CONFIG=`which libpng-config` > fi Why not just using pkg-config ? (which would be _much_ more distmaintainer/packager-friendly) PKG_CHECK_MODULE([...]) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

Jan. 29, 2011

Final release of FLTK 2.0 Dillo

by itsme_410＠yahoo.com

I wonder what a projected timeline for the 1.3 release will be.... T --- On Tue, 1/25/11, Alexander Voigt <Hole.destructor(a)gmx.de> wrote: > From: Alexander Voigt <Hole.destructor(a)gmx.de> > Subject: [Dillo-dev] Final release of FLTK 2.0 Dillo > To: "Dillo Mailinglist" <dillo-dev(a)dillo.org> > Date: Tuesday, January 25, 2011, 3:21 AM > Dear Dillo developers, > > since you started porting Dillo to FLTK 1.3, I wonder if > you plan to > do a last release of the current FLTK 2.0 Dillo?? > (This would seem > reasonable to me, since this version works pretty well and > some of us > can't wait so long for the next release. :) > > Many thanks in advance, > Alexander Voigt > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 29, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

Jeremy Henty wrote: > *Bump* Can I push this or are there objections? OK, I think I got enough encouragement to justify a push, so I have. Regards, Jeremy Henty

Jan. 28, 2011

[patch]: clean up the build and make d_size.h static.

by Johannes.Hofmann＠gmx.de

On Mon, Jan 17, 2011 at 08:58:04PM +0000, Jeremy Henty wrote: > corvid wrote: > > Jeremy wrote: > > > corvid wrote: > > > > > > > Found the problem. > > > > > > > > The autoconf 2.66 release announcement > > > > http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html > > > > includes: > > > > > > > > ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and > > > > AC_TYPE_INT64_T work again. Regression introduced in 2.65. > > > > > So is this a reason to hold back this patch? > > > > I...don't think so. > > My thinking went: > > 1. It broke harmlessly. > > 2. But maybe it would break seriously for someone else. > > 3. But if we'd made the change before 2.65 came out, would we do > > anything about it, or would we say "Well, that's too bad for > > autoconf-2.65"? No doubt the latter unless we knew of real > > breakage. > > So is it OK to push? Does anyone else have comments? I like the change and we are at autoconf-2.68 now - but I don't feel very competent in this area. Cheers, Johannes

Jan. 27, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

Jeremy Henty wrote: > corvid wrote: > > Jeremy wrote: > > > corvid wrote: > > > > > > > Found the problem. > > > > > > > > The autoconf 2.66 release announcement > > > > http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html > > > > includes: > > > > > > > > ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and > > > > AC_TYPE_INT64_T work again. Regression introduced in 2.65. > > > > > So is this a reason to hold back this patch? > > > > I...don't think so. > > My thinking went: > > 1. It broke harmlessly. > > 2. But maybe it would break seriously for someone else. > > 3. But if we'd made the change before 2.65 came out, would we do > > anything about it, or would we say "Well, that's too bad for > > autoconf-2.65"? No doubt the latter unless we knew of real > > breakage. > > So is it OK to push? Does anyone else have comments? *Bump* Can I push this or are there objections? Regards, Jeremy Henty

Jan. 27, 2011

1.3 port status

by rogerx.oss＠gmail.com

>On top of that, this "solution" doesn't really solve anything -- it >still takes time away from development, requires developers to learn >the new abstraction layer, and won't make up for functional >incompatibilities/missing features between different toolkits or >versions. ?It sounds like a great idea in theory -- and IIRC, the >Dillo renderer (but not the rest of the interface) is already built on >an abstraction layer -- but in practice it would mostly amount to >needlessly re-inventing the wheel. > >Disclaimer: I'm not one of the core developers, and this is only my >personal view. > >~Benjamin It sounds like your issues would be more effectively resolved if you posted them to the fltk mailing list. Or, the news & blog threads concerning fltk versioning. Although from what they have stated, almost all development has occurred within the fltk-1.3 branch for the past year, still somebody posted concerning pushing further development on fltk-2.0 recently. <sigh> I'm just going with the flow here.

Jan. 27, 2011

1.3 port status

by obeythepenguin＠gmail.com

On 1/26/11, corvid <corvid(a)lavabit.com> wrote: > Benjamin, > > 1) If your boat is sinking, you get into a different boat. All I'm saying is Dillo seems to get into a *lot* of leaky boats. > 2) Man, the idea with Free Software is community and sharing and > common good, and not Corvid-does-everything-himself. I didn't mean that as personal criticism -- I was simply pointing out how the situation might look to an outsider not really active in Dillo development. (I work as a technical editor, so reading too much into things is literally my job.) My point, in short, is that Dillo's already had to switch from one obsolete toolkit, and doing it again doesn't reflect well on the project, however necessary or justified it is. This is the "damned if you do" to everyone else's collective "damned if you don't." But I suppose I've wasted enough words in making my point. ~Benjamin

Jan. 26, 2011

1.3 port status

by corvid＠lavabit.com

Benjamin, 1) If your boat is sinking, you get into a different boat. 2) Man, the idea with Free Software is community and sharing and common good, and not Corvid-does-everything-himself.

Jan. 26, 2011

patch: configure rm libpng version tests

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote: > > [...] > > Is there a good reason not to use whatever libpng-config is linked to? > > I don't know these days, but a few years ago I had to add all > of those tests because of different names of the configure script > and there were distros packing two versions of the library and > using the script name to differentitate among them. > > *Handle with care* Okay, how about rearranging to put libpng-config first to get whatever they prefer, and we can add in backup tests for versions with less... I was going to say 'urgency', but of course we haven't released a version that handles 1.4 yet... (Aside: With eleven years of history now, we seem to run into a lot of "I think a long time ago, we needed that for something" which suggests that we should be a bit obsessive about our documentation. Sometimes you can get a hint from the list archives, but often the pattern is "A release looms, and someone contacts Jorge off-list about whatever problem, and it is quietly patched".)

Jan. 26, 2011

1.3 port status

by obeythepenguin＠gmail.com

Oops, I meant to send this to the list, not just Alexander -- apologies for that. On Wed, Jan 26, 2011 at 9:12 AM, Alexander Voigt <Hole.destructor(a)gmx.de> wrote: > Maybe this is a solution to the upcomming problem(s). ?What one needs > to do is to build an abstraction and an implementor and pack all > toolkit specific things into concrete implementors (i.e. the FLTK 2.0, > or FLTK 1.3 specific things). There's one obvious problem there: the toolkit is *already* an abstraction. ?(FLTK's not strictly an abstraction layer, because it implements its own widget set, but the purpose of any toolkit is to provide some sort of abstraction over the native APIs.) On top of that, this "solution" doesn't really solve anything -- it still takes time away from development, requires developers to learn the new abstraction layer, and won't make up for functional incompatibilities/missing features between different toolkits or versions. ?It sounds like a great idea in theory -- and IIRC, the Dillo renderer (but not the rest of the interface) is already built on an abstraction layer -- but in practice it would mostly amount to needlessly re-inventing the wheel. Disclaimer: I'm not one of the core developers, and this is only my personal view. ~Benjamin

Jan. 26, 2011

1.3 port status

by Hole.destructor＠gmx.de

Dear Dillo developers. > - Twelve years and three toolkits later, there's still no support > for such basic functionality as floating elements (HTML "align=" or > CSS "float:"). See my other two points. If you allow, I would like to make a constructive proposal at this point. There is an interesting Object Orientated Design Pattern called `Bridge', which is intended to separate an abstraction from the implementation. This is especially convenient if one wants to support more than one toolkit or the toolkit changes frequently. (I think one is not forced to use C++ for this purpose. It should be possible to use pure C and select the concrete implementation at compile time.) Maybe this is a solution to the upcomming problem(s). What one needs to do is to build an abstraction and an implementor and pack all toolkit specific things into concrete implementors (i.e. the FLTK 2.0, or FLTK 1.3 specific things). For examples see: http://en.wikipedia.org/wiki/Bridge_pattern and Gamma, E, Helm, R, Johnson, R, Vlissides, J: Design Patterns, page 151. Addison-Wesley, 1995 Kind regards, Alexander Voigt

Jan. 26, 2011

1.3 port status

by obeythepenguin＠gmail.com

On Wed, 26 Jan 2011 01:42:38 -0500, corvid <corvid(a)lavabit.com> wrote: > The hope is that someone (with any luck, not me) will > learn enough FLTK 1.3 to figure out how to make it nice. I'm sorry, but everything about that sentence makes me cringe. Not meaning this to attack anyone personally, but here's how I'd read the situation as an outsider: - Project leadership wants to switch toolkits, not for the first time. This takes time away from "real" development work (new features, bugfixes, documentation...), and suggests poor planning and indecisiveness. - The current developers aren't familiar with the new toolkit, and suggest -- seriously or otherwise -- they aren't particularly interested in learning it. This takes even more time away from real development, potentially results in buggier, lower quality software, and suggests all sorts of other things besides. - Twelve years and three toolkits later, there's still no support for such basic functionality as floating elements (HTML "align=" or CSS "float:"). See my other two points. I really like Dillo, and I really enjoy hacking on it (both for the code and the great development team). But the whole toolkit situation is throwing up all sorts of red flags, so I hope you can forgive me for voicing a few concerns. ~Benjamin

Jan. 26, 2011

patch: configure rm libpng version tests

by jcid＠dillo.org

On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote: > [...] > Is there a good reason not to use whatever libpng-config is linked to? I don't know these days, but a few years ago I had to add all of those tests because of different names of the configure script and there were distros packing two versions of the library and using the script name to differentitate among them. *Handle with care* -- Cheers Jorge.-

Jan. 26, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Wed, Jan 26, 2011 at 05:42:33AM +0000, corvid wrote: > Hmm, a quick attempt to look through the autoconf manual doesn't say anything > about how to tell --help to list env variables. What is generally done? AC_ARG_VAR, I think. Joerg

Jan. 26, 2011

1.3 port status

by corvid＠lavabit.com

Yeah, the UI is just rough; that's why it's in a patch and not committed. The hope is that someone (with any luck, not me) will learn enough FLTK 1.3 to figure out how to make it nice. Making a true equivalent to fltk::PackedGroup would go a long way there, for one thing.

Jan. 26, 2011

1.3 port status

by rogerx.oss＠gmail.com

>Other then these, dillo built against fltk-1.3 looks fully functional to me so >far. ...might be one or two more quirks. One more GUI bug found, the "X" at the far upper right corner for closing tabs/windows appears to be completely missing. (imo, it's usually much easier to click ctrl-q anyways. ;-) -- Roger http://rogerx.freeshell.org/

Jan. 26, 2011

1.3 port status

by rogerx.oss＠gmail.com

> On Mon, Jan 24, 2011 at 11:03:35PM +0000, corvid wrote: >Roger wrote: >> I was just using hg update (after the initial hg clone $url). > >hg update is something different. You use hg pull to get changes >from a repository. > >> Here's my description now, pages load, even news.google.com loads! Scrolling >> on news.google.com pauses/lags at times. No images loaded on news.google.com. > >Right now, the scrolling doesn't happen while the cursor wanders >outside of the scrollbar bounds. > >> As for the dillo interface, tabs appear after a few seconds/minutes of mouse >> wandering. I do have buttons, but the "File, View, ..." buttons are still >> hidden. > >After mouse wandering? Of their own accord? >View? I think I see one cause of a bug of the GUI. When opening a bookmark from dpi:/bm/ by right clicking and seleting "open link in new tab", the refresh to redraw the GUI frontend is not occurring. As such, the new tab is created invisibily and the GUI isn't refreshed showing the new tab has been opened until the user tries clicking one of the tabs. Now, once the bookmark url has been visited (I'm guessing cached), closing the tab and then reopening the tab via the same bookmark method as described above, the new tab will be visibily created and the GUI bug can no longer being seen. I'm guessing, a full window or GUI refresh or redraw is being dropped somewhere? Concerning the "File" button above the tab bar, I have none showing ... oh wait, thar it is! It's a big "F" button on the button bar next to the "Tools" button! Other then these, dillo built against fltk-1.3 looks fully functional to me so far. ...might be one or two more quirks. -- Roger http://rogerx.freeshell.org/

Jan. 26, 2011

patch: configure rm libpng version tests

by corvid＠lavabit.com

Joerg wrote: > On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote: > > Is there a good reason not to use whatever libpng-config is linked to? > > I like the idea of not having to touch configure.in every time there's > > a new minor version, especially given how long we go between releases. > > As long as the libpng-config can be overriden by environment / configure > argument and the name of the variable is documented, that's fine. There is a $PNG_CONFIG in there. Hmm, a quick attempt to look through the autoconf manual doesn't say anything about how to tell --help to list env variables. What is generally done?

Jan. 26, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote: > Joerg wrote: > > On Wed, Jan 26, 2011 at 02:42:19AM +0000, corvid wrote: > > > It seems that libpng is up to 1.5.0 now, so it's time to rip > > > out some version tests. > > > > libpng 1.5.0 also creates a lot of fallout, so expect users to stay with > > 1.4 for a while... > > In that people don't like the changes hiding data structures, or > that it will take time before developers get their software sorted > out to handle it? A lot of software was broken by it and it will take time to sort that out. > Is there a good reason not to use whatever libpng-config is linked to? > I like the idea of not having to touch configure.in every time there's > a new minor version, especially given how long we go between releases. As long as the libpng-config can be overriden by environment / configure argument and the name of the variable is documented, that's fine. Joerg

Jan. 26, 2011

patch: configure rm libpng version tests

by corvid＠lavabit.com

Joerg wrote: > On Wed, Jan 26, 2011 at 02:42:19AM +0000, corvid wrote: > > It seems that libpng is up to 1.5.0 now, so it's time to rip > > out some version tests. > > libpng 1.5.0 also creates a lot of fallout, so expect users to stay with > 1.4 for a while... In that people don't like the changes hiding data structures, or that it will take time before developers get their software sorted out to handle it? Is there a good reason not to use whatever libpng-config is linked to? I like the idea of not having to touch configure.in every time there's a new minor version, especially given how long we go between releases.

Jan. 26, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Wed, Jan 26, 2011 at 02:42:19AM +0000, corvid wrote: > It seems that libpng is up to 1.5.0 now, so it's time to rip > out some version tests. libpng 1.5.0 also creates a lot of fallout, so expect users to stay with 1.4 for a while... Joerg

Jan. 26, 2011

patch: configure rm libpng version tests

by corvid＠lavabit.com

It seems that libpng is up to 1.5.0 now, so it's time to rip out some version tests.

Jan. 26, 2011

Final release of FLTK 2.0 Dillo

by corvid＠lavabit.com

What do we need to fix before we could have a release?

Jan. 25, 2011

Final release of FLTK 2.0 Dillo

by obeythepenguin＠gmail.com

*thinks switching toolkits every couple years was never a good idea to begin with* On 1/25/11, corvid <corvid(a)lavabit.com> wrote: > Johannes wrote: >> On Tue, Jan 25, 2011 at 08:21:35AM +0000, Alexander Voigt wrote: >> > Dear Dillo developers, >> > >> > since you started porting Dillo to FLTK 1.3, I wonder if you plan to >> > do a last release of the current FLTK 2.0 Dillo? (This would seem >> > reasonable to me, since this version works pretty well and some of us >> > can't wait so long for the next release. :) >> >> Sounds like a good idea. > > *agrees* > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 25, 2011

Final release of FLTK 2.0 Dillo

by corvid＠lavabit.com

Johannes wrote: > On Tue, Jan 25, 2011 at 08:21:35AM +0000, Alexander Voigt wrote: > > Dear Dillo developers, > > > > since you started porting Dillo to FLTK 1.3, I wonder if you plan to > > do a last release of the current FLTK 2.0 Dillo? (This would seem > > reasonable to me, since this version works pretty well and some of us > > can't wait so long for the next release. :) > > Sounds like a good idea. *agrees*

Jan. 25, 2011

Final release of FLTK 2.0 Dillo

by johannes.hofmann＠gmx.de

On Tue, Jan 25, 2011 at 08:21:35AM +0000, Alexander Voigt wrote: > Dear Dillo developers, > > since you started porting Dillo to FLTK 1.3, I wonder if you plan to > do a last release of the current FLTK 2.0 Dillo? (This would seem > reasonable to me, since this version works pretty well and some of us > can't wait so long for the next release. :) Sounds like a good idea. Cheers, Johannes

Jan. 25, 2011

Final release of FLTK 2.0 Dillo

by Hole.destructor＠gmx.de

Dear Dillo developers, since you started porting Dillo to FLTK 1.3, I wonder if you plan to do a last release of the current FLTK 2.0 Dillo? (This would seem reasonable to me, since this version works pretty well and some of us can't wait so long for the next release. :) Many thanks in advance, Alexander Voigt

Jan. 25, 2011