- Dillo-dev - lists.mailman3.com

a little experiment in showing form encoding as a tooltip

by corvid＠lavabit.com

Currently, there's a MSG that tells you what encoding a form was submitted as -- once it's submitting it. Obviously that's of limited usefulness when you want to know beforehand what will happen to any Japanese that you might type in, but on other hand, so many pages have forms that MSGs ahead of time would be annoying, besides the fact that a page may have multiple forms with different accept-charset attrs... Add to that the fact that one has to learn the hard way that you should only paste utf-8 into dillo2 and not, say, windows-1257. (and latin-1 works because fltk assumes it's latin-1 and does the conversion) So my quick little experiment: text/password/textarea form controls display a tooltip that reads enter: UTF-8 when UTF-8 will be submitted, and enter: UTF-8 send as: [some other encoding] otherwise. And it would clear things up for every person who tried to use google.com and wondered why non-latin-1 wasn't working when the oh-so-glorious dillo2 is supposed to be all UTF-8ed up. After all, it works in Firefox, right? (I've read that google pulls this idiocy with all of the little browsers. w3m, elinks, etc. Ignores the Accept-Charset header and does what it wants based on the User-Agent.) A different option might be to have a form popup menu to show info such as submission encoding, hidden inputs, and so on. As for the code, unfortunately I have setTooltip()s all over the place because Style's Tooltip field is for real tooltips, not for char*s to stuff into pre-existing tooltips such as the fltk widgets have.

Sept. 3, 2008

patch: make image inputs less of a special case

by jcid＠dillo.org

On Mon, Sep 01, 2008 at 12:24:48AM +0000, corvid wrote: > - have the complex button resource remember its click x,y. > - just use the Activate signal instead of Clicked > - don't have to carry x,y through so much of the form code. > - use appendValues instead of that special case in buildQueryData. Nice simplification! Committed. > (Jorge: I have another version of the form action url display patch, > but this jumped ahead of it somehow) ACK. -- Cheers Jorge.-

Sept. 1, 2008

an example of page redraw problem when images load

by Johannes.Hofmann＠gmx.de

On Sat, Aug 09, 2008 at 03:26:48PM +0000, corvid wrote: > With automatic image loading turned off, if I go to > http://genode.org/documentation/developer-resources/walk_through , > page down to the [IMG] below "The launchpad application starter", > and click on it, the space to the right of the image still contains > remnants of the text that used to be there. This is a bug in the redraw optimization. I could reproduce it once with the method you described, but now it no longer happens. Also it does not happen here with a local testcase like: <html> <body> foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar <img src="test.jpg"/> foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar </body> </html> I'll keep trying... Johannes

Sept. 1, 2008

init_rawdatabuffer is slow.

by Johannes.Hofmann＠gmx.de

On Tue, Aug 26, 2008 at 06:13:23PM +0000, corvid wrote: > That's the code that paints the stripes that you see initially in images. > > Here's what gprof said when I loaded a 2 meg jpeg: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 34.76 0.57 0.57 1 570.00 570.00 dw::fltk::init_rawdatabuffer(int, int, int, int, unsigned char > 26.83 1.01 0.44 1536 0.29 0.29 dw::fltk::FltkImgbuf::copyRow(int, unsigned char const*) > 25.00 1.42 0.41 379 1.08 1.08 dStr_insert_l > 7.32 1.54 0.12 rgb_to_565d(unsigned char const*, unsigned char*, int, int) > 0.61 1.55 0.01 7759 0.00 0.00 lout::container::untyped::Iterator::hasNext() > .. > > > If I take out the init_rawdatabuffer() call and put in a bzero() instead, > I get: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 51.43 0.54 0.54 1536 0.35 0.36 dw::fltk::FltkImgbuf::copyRow(int, unsigned char const*) > 34.29 0.90 0.36 373 0.97 0.97 dStr_insert_l > 5.71 0.96 0.06 rgb_to_565d(unsigned char const*, unsigned char*, int, int) > 1.90 0.98 0.02 a_Image_imgbuf_new > 0.95 0.99 0.01 10868 0.00 0.00 lout::container::untyped::Collection0::AbstractIterator::unref() > .. > > > Any objections, then, to having pictures start out black instead of striped? > Excellent! It really makes a difference in performance - and looks better... Johannes

Sept. 1, 2008

patch: make image inputs less of a special case

by corvid＠lavabit.com

- have the complex button resource remember its click x,y. - just use the Activate signal instead of Clicked - don't have to carry x,y through so much of the form code. - use appendValues instead of that special case in buildQueryData. (Jorge: I have another version of the form action url display patch, but this jumped ahead of it somehow)

Sept. 1, 2008

Bugtrack DB updated

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 29, 2008 at 07:41:46PM +0000, corvid wrote: > > Jorge wrote: > > > On Fri, Aug 29, 2008 at 04:47:57PM +0000, corvid wrote: > > > > Perhaps it would be of some value to have a document showing, like... > > > > cache: what you said. > > > > anim. gifs: none of the current developers want the feature, but > > > > a good patch will be accepted if it can be disabled. > > > > forms remembering data: that i've been sort of considering it -- with > > > > mixed feelings -- but have not felt any > > > > great urgency regarding this matter :) > > > > AUTH: if I were given a way to test it, I'd be willing to look into > > > > the matter in case it turned out to be trivial, but wouldn't promise > > > > anything more. > > > > png backgrounds: that I tried once, did not succeed, but still have > > > > the code if anybody should want to dig into it. > > > > punctuation wrapping: none of the current developers have shown much > > > > interest in dealing with textblock.cc. > > > > etc...etc... > > > > > > Yes, more or less that's the point. ;) > > > > Of the bug tracker as it is now? > > Strange as it may look: I'd rather prefer a bugtracker with a > few entries that are being worked-on than a complete one whith a > long list that no-one cares enough to work on. And most probably > the best point lies somewhere in the middle (as the current > bugtracker). > > Of course a detailed list gives a good idea of what's to be > done, and if there're developers willing to work on them that's > great, but watching the same entries unworked for years makes me > think this way. > > If you see a way to improve the situation please feel free to do. I'm not sure that I see how deleting some of the entries will cause other entries to be worked on, but oh well... *tires of topic at last*

Aug. 30, 2008

Bugtrack DB updated

by jcid＠dillo.org

On Fri, Aug 29, 2008 at 07:41:46PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Aug 29, 2008 at 04:47:57PM +0000, corvid wrote: > > > Perhaps it would be of some value to have a document showing, like... > > > cache: what you said. > > > anim. gifs: none of the current developers want the feature, but > > > a good patch will be accepted if it can be disabled. > > > forms remembering data: that i've been sort of considering it -- with > > > mixed feelings -- but have not felt any > > > great urgency regarding this matter :) > > > AUTH: if I were given a way to test it, I'd be willing to look into > > > the matter in case it turned out to be trivial, but wouldn't promise > > > anything more. > > > png backgrounds: that I tried once, did not succeed, but still have > > > the code if anybody should want to dig into it. > > > punctuation wrapping: none of the current developers have shown much > > > interest in dealing with textblock.cc. > > > etc...etc... > > > > Yes, more or less that's the point. ;) > > Of the bug tracker as it is now? Strange as it may look: I'd rather prefer a bugtracker with a few entries that are being worked-on than a complete one whith a long list that no-one cares enough to work on. And most probably the best point lies somewhere in the middle (as the current bugtracker). Of course a detailed list gives a good idea of what's to be done, and if there're developers willing to work on them that's great, but watching the same entries unworked for years makes me think this way. If you see a way to improve the situation please feel free to do. -- Cheers Jorge.-

Aug. 30, 2008

Bugtrack DB updated

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 29, 2008 at 04:47:57PM +0000, corvid wrote: > > Perhaps it would be of some value to have a document showing, like... > > cache: what you said. > > anim. gifs: none of the current developers want the feature, but > > a good patch will be accepted if it can be disabled. > > forms remembering data: that i've been sort of considering it -- with > > mixed feelings -- but have not felt any > > great urgency regarding this matter :) > > AUTH: if I were given a way to test it, I'd be willing to look into > > the matter in case it turned out to be trivial, but wouldn't promise > > anything more. > > png backgrounds: that I tried once, did not succeed, but still have > > the code if anybody should want to dig into it. > > punctuation wrapping: none of the current developers have shown much > > interest in dealing with textblock.cc. > > etc...etc... > > Yes, more or less that's the point. ;) Of the bug tracker as it is now?

Aug. 29, 2008

Bugtrack DB updated

by jcid＠dillo.org

On Fri, Aug 29, 2008 at 04:47:57PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Aug 29, 2008 at 03:05:04PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Fri, Aug 29, 2008 at 01:56:44PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > The Bugtrack DB was updated for dillo2 too. > > > > > > > > > > When I compare it to an old copy I have locally, > > > > > it appears as if entries were deleted randomly > > > > > rather than because they have been fixed. > > > > > > > > > > e.g., starting at the top, there used to be > > > > > 127. "optgroup is ignored...", and optgroup is > > > > > still commented out in Tags. > > > > > But > > > > > 128. "in form, input type=file is ignored..." > > > > > remains, even though I implemented that. > > > > > > > > They were not deleted at random. > > > > > > > > I checked lots of them and set "done" on the ones that work. > > > > This is with regard to dillo2. If they still don't work in dillo1 > > > > doesn't matter. > > > > > > I set done on things a while back if they worked, > > > (sometimes leaving UI ones if the fltk replacement feature still > > > had its own brokenness). > > > > > > > Along the long way a few were deleted... I also wondered whether > > > > to start with a clean bug-track, but preferred to comb the whole > > > > DB and try to keep the valuable information. > > > > > > > > If you take a bigger sample, the first impression may change. > > > > > > Let's see. Starting from the top: > > > > fixed: YES deleted: NO is OK as long as its marked as "done" > > (they are removed once the release is made) > > > > fixed: NO deleted: NO is OK > > fixed: NO deleted: YES is a mistake (unless a "won't fix") > > > > > > I'll comment the mistakes: > > > > > > > 127. optgroup. fixed: NO deleted: YES > > > > May be re-inserted. > > > > > 128. file input. fixed: YES deleted: NO > > > 131. frames. fixed: NO deleted: YES > > > > Duplicated, 660 is the same (and has an email) > > Ah, so the old ones get deleted as dups of the new ones. > That is not the way I expected this to work. > But it improves our metrics. > > > > 138. anim. gifs. fixed: NO deleted: NO > > > 159. cache limit. fixed: NO deleted: YES > > > 161. cache control. fixed: NO deleted: YES > > > > Kind of a "won't fix" for the moment. > > One of the ideas of the cache is not loosing the visited pages > > upon Bck/Fwd or when offline. Implementing this would need a new > > cache design. > > Pulling out wontfixes? > > Perhaps it would be of some value to have a document showing, like... > cache: what you said. > anim. gifs: none of the current developers want the feature, but > a good patch will be accepted if it can be disabled. > forms remembering data: that i've been sort of considering it -- with > mixed feelings -- but have not felt any > great urgency regarding this matter :) > AUTH: if I were given a way to test it, I'd be willing to look into > the matter in case it turned out to be trivial, but wouldn't promise > anything more. > png backgrounds: that I tried once, did not succeed, but still have > the code if anybody should want to dig into it. > punctuation wrapping: none of the current developers have shown much > interest in dealing with textblock.cc. > etc...etc... Yes, more or less that's the point. ;) -- Cheers Jorge.-

Aug. 29, 2008

Bugtrack DB updated

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 29, 2008 at 03:05:04PM +0000, corvid wrote: > > Jorge wrote: > > > On Fri, Aug 29, 2008 at 01:56:44PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > The Bugtrack DB was updated for dillo2 too. > > > > > > > > When I compare it to an old copy I have locally, > > > > it appears as if entries were deleted randomly > > > > rather than because they have been fixed. > > > > > > > > e.g., starting at the top, there used to be > > > > 127. "optgroup is ignored...", and optgroup is > > > > still commented out in Tags. > > > > But > > > > 128. "in form, input type=file is ignored..." > > > > remains, even though I implemented that. > > > > > > They were not deleted at random. > > > > > > I checked lots of them and set "done" on the ones that work. > > > This is with regard to dillo2. If they still don't work in dillo1 > > > doesn't matter. > > > > I set done on things a while back if they worked, > > (sometimes leaving UI ones if the fltk replacement feature still > > had its own brokenness). > > > > > Along the long way a few were deleted... I also wondered whether > > > to start with a clean bug-track, but preferred to comb the whole > > > DB and try to keep the valuable information. > > > > > > If you take a bigger sample, the first impression may change. > > > > Let's see. Starting from the top: > > fixed: YES deleted: NO is OK as long as its marked as "done" > (they are removed once the release is made) > > fixed: NO deleted: NO is OK > fixed: NO deleted: YES is a mistake (unless a "won't fix") > > > I'll comment the mistakes: > > > > 127. optgroup. fixed: NO deleted: YES > > May be re-inserted. > > > 128. file input. fixed: YES deleted: NO > > 131. frames. fixed: NO deleted: YES > > Duplicated, 660 is the same (and has an email) Ah, so the old ones get deleted as dups of the new ones. That is not the way I expected this to work. But it improves our metrics. > > 138. anim. gifs. fixed: NO deleted: NO > > 159. cache limit. fixed: NO deleted: YES > > 161. cache control. fixed: NO deleted: YES > > Kind of a "won't fix" for the moment. > One of the ideas of the cache is not loosing the visited pages > upon Bck/Fwd or when offline. Implementing this would need a new > cache design. Pulling out wontfixes? Perhaps it would be of some value to have a document showing, like... cache: what you said. anim. gifs: none of the current developers want the feature, but a good patch will be accepted if it can be disabled. forms remembering data: that i've been sort of considering it -- with mixed feelings -- but have not felt any great urgency regarding this matter :) AUTH: if I were given a way to test it, I'd be willing to look into the matter in case it turned out to be trivial, but wouldn't promise anything more. png backgrounds: that I tried once, did not succeed, but still have the code if anybody should want to dig into it. punctuation wrapping: none of the current developers have shown much interest in dealing with textblock.cc. etc...etc... > > 185. "Tables, part II: structure elements" fixed: depends on whether that > > means thead et al. deleted: YES > > Not very descriptive. Major work needing a new head developer. > Sebastian name there was misleading in the sense that is was being worked. > > > 220. forms don't remember data. fixed: NO deleted: YES > > Needs a re-insert (I thought it was duplicated). > > > 224. AUTH. fixed: NO deleted: NO > > 242. CSS. fixed: NO deleted: NO > > 245. image-broken indicator. fixed: NO deleted: NO > > 250. PNG alpha different bgrounds. fixed: NO deleted: YES > > Duplicated with 542. > > > 270. punctuation wrapping. fixed: NO deleted: YES > > Example URL doesn't exist anymore. But any stretch of, like, "<a href=sdfsfl>ksjfk</a>, ksdjfds" shows the problem. *checks whether you deleted the  one as well* You did. But...soft hyphens don't work... > > 281. non-latin-1 charsets. fixed: YES deleted: NO

Aug. 29, 2008