- Dillo-dev - lists.mailman3.com

a little experiment in showing form encoding as a tooltip

by corvid＠lavabit.com

Jorge wrote: > On Tue, Sep 02, 2008 at 10:30:40PM +0000, corvid wrote: > > 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. > > That's a good start... > > > > 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.) > > It may be a but more complicated. Non-technical users may be > left wondering what to do with that message or what UTF-8 is. For > instance, I don't know how to input latin1 from an X environment > that's set to utf8 (besides switching the whole thing to latin1). > > AFAIU, which is not much in this regard, if there's a way to > know what encoding the X server is using, dillo may iconv it into > utf8 and then to the "send-charset" if necessary (in a similar > way to what FLTK2 does with latin1). > > That way it works for the user without further steps. Of course > I may be wrong in this appreciation! > > > Would you mind explaining it further? > > It deserves at least an entry in the FAQ (which I would read > with interest, certainly ;). I had been looking at this from the perspective of: "even though copy and paste of latin2 between two rxvt's works, I can't paste latin2 into dillo", but I suppose I'm not quite sure that X wouldn't have enough magic in it for latin2 to work for someone properly set up in a latin2 locale. Looking at the format of the Compose file, I _think_ it still wouldn't work for them (<Multi_key> <L> <minus> becomes "\243", not "Lstroke". Of course they don't need the Compose mapping, but the fact that it's going toward the octal encoding rather than a character seems significant). Putting aside what character encoding to enter, not knowing what encoding a form will be submitted as bugs me. Somewhat related to all of this: local files that are text/plain.

Sept. 5, 2008

Keyboard scrolling and focus patch

by jcid＠dillo.org

On Thu, Sep 04, 2008 at 10:51:56PM +0200, Johannes Hofmann wrote: > > > > Please test, and enjoy. > > Nice. Thanks you! :-) > > PS: I've also made some experiments with tabs, but it seems FLTK2 > > has problems to handle window widgets inside the tabs... > > Why do You need a window (instead of a simple widget) inside the > tabs? Currently dillo2 uses window, so Ctrl-N can open a new window. It would have been convenient not to change the current code base, and to reuse that already tested part for both tabs and new windows (with the idea of being able to open tabs or new windows with the same code). It may be possible by switching class UI to derive from Group, and to add an enclosing window only when necessary, and thus arrange for widgets inside Tabs and Window for windows. The problem I foresee with the latter scheme is messing with the event passing between widgets and windows... I'll have to experiment with it, and get some working code. Now, if *somebody* wants to help then, that'd be great! ;-) -- Cheers Jorge.-

Sept. 4, 2008

a little experiment in showing form encoding as a tooltip

by jcid＠dillo.org

Hi, On Tue, Sep 02, 2008 at 10:30:40PM +0000, corvid wrote: > 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. That's a good start... > 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.) It may be a but more complicated. Non-technical users may be left wondering what to do with that message or what UTF-8 is. For instance, I don't know how to input latin1 from an X environment that's set to utf8 (besides switching the whole thing to latin1). AFAIU, which is not much in this regard, if there's a way to know what encoding the X server is using, dillo may iconv it into utf8 and then to the "send-charset" if necessary (in a similar way to what FLTK2 does with latin1). That way it works for the user without further steps. Of course I may be wrong in this appreciation! Would you mind explaining it further? It deserves at least an entry in the FAQ (which I would read with interest, certainly ;). -- Cheers Jorge.-

Sept. 4, 2008

Keyboard scrolling and focus patch

by jcid＠dillo.org

Hi there, Finally a patch for fixing keyboard scrolling, and focus change with the keyboard, was committed. I had hopes to be able to commit before the release, and so I'm happy. :) Now switching focus from the viewport to the location bar, using the keyboard, works consistently (Try TAB/Shift-TAB) and also the scrolling keys (Up, Down, Left, Right, PgUp/b, PgDn/space, etc) are kept in a responsive state. It's been a long time, and I almost forgot the nice feeling of scrolling with the keyboard (e.g. try the space bar to skip past the links menu most pages have these days). Please test, and enjoy. -- Cheers Jorge.- PS: I've also made some experiments with tabs, but it seems FLTK2 has problems to handle window widgets inside the tabs...

Sept. 4, 2008

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

Bugtrack DB updated

by jcid＠dillo.org

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) > 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. > 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. > 281. non-latin-1 charsets. fixed: YES deleted: NO -- Cheers Jorge.-

Aug. 29, 2008

Bugtrack DB updated

by corvid＠lavabit.com

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: 127. optgroup. fixed: NO deleted: YES 128. file input. fixed: YES deleted: NO 131. frames. fixed: NO deleted: YES 138. anim. gifs. fixed: NO deleted: NO 159. cache limit. fixed: NO deleted: YES 161. cache control. fixed: NO deleted: YES 185. "Tables, part II: structure elements" fixed: depends on whether that means thead et al. deleted: YES 220. forms don't remember data. fixed: NO deleted: YES 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 270. punctuation wrapping. fixed: NO deleted: YES 281. non-latin-1 charsets. fixed: YES deleted: NO (gets bored) First impression has not changed.

Aug. 29, 2008

Bugtrack DB updated

by jcid＠dillo.org

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. 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. -- Cheers Jorge.-

Aug. 29, 2008

Bugtrack DB updated

by corvid＠lavabit.com

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.

Aug. 29, 2008

Bugtrack DB updated

by jcid＠dillo.org

Hi, The Bugtrack DB was updated for dillo2 too. -- Cheers Jorge.-

Aug. 29, 2008

web site partial update

by joerg.sonnenberger＠web.de

On Thu, Aug 28, 2008 at 12:27:57PM -0400, Jorge Arellano Cid wrote: > BTW, what version number should we give to dillo2? > 2.0 seems like a good candidate. Start with 1.99.0 and provide a first real alpha release? Joerg

Aug. 28, 2008

web site partial update

by jcid＠dillo.org

Hi, With a view to prepare our next dillo2 release, the web site has been partially updated. From the links column, these sections: Developers, Users, Related and "Hosted at" are up to date. Even the downloadable alternative icons work, and pages were bug-meter validated too. BTW, what version number should we give to dillo2? 2.0 seems like a good candidate. -- Cheers Jorge.-

Aug. 28, 2008

init_rawdatabuffer is slow.

by jcid＠dillo.org

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? OK, light gray using (memset) was committed as the new interim image background. -- Cheers Jorge.-

Aug. 27, 2008

init_rawdatabuffer is slow.

by corvid＠lavabit.com

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?

Aug. 26, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

Christopher Illies wrote: > On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > > I wonder whether we could get someone for each system who > > would have the responsibility (or, let's say "_glory_" :) > > of responding to "Hey, we changed [some configuration stuff] > > in the latest CVS. Does it work fine on your system?" messages. > > I can take that part for FreeBSD for now and will respond when such > messages are posted to this list. Also, I can do a fresh compile every > two weeks or so. Cool!

Aug. 26, 2008

a list of what dillo2 runs on

by christopher.illies＠ki.se

On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > I wonder whether we could get someone for each system who > would have the responsibility (or, let's say "_glory_" :) > of responding to "Hey, we changed [some configuration stuff] > in the latest CVS. Does it work fine on your system?" messages. I can take that part for FreeBSD for now and will respond when such messages are posted to this list. Also, I can do a fresh compile every two weeks or so. Christopher

Aug. 26, 2008

patch: make prefs.c and dillorc2 consistent

by corvid＠lavabit.com

Jorge wrote: > > In other news, I was just starting to play with the > > mangleme fuzzer that Justus mentioned some months back. > Oh, I missed that email. Where's the fuzzer? earlier thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-May/004395.html fuzzer: http://lcamtuf.coredump.cx/soft/mangleme.tgz

Aug. 26, 2008

Re: patch: disallow textarea/button inside select

by jcid＠dillo.org

On Sun, Aug 24, 2008 at 01:25:02AM +0000, corvid wrote: > Putting aside the Stash one for something easy > (with Stash, the html file is like 90K, and it > seems like touching any of it makes the crashing > stop, so...), I find that textarea or button inside > select is bad because close_select assumes that > current input is a select. > > An alternative would be to make close_select > check the current input, but then other > controls aren't supposed to be inside it anyway... > > I feel like we already had this bug and fixed it, > but I must be thinking of whatever specifically made > us add the IN_SELECT test to open_input. We may find a canonical way to implement this constraints in the future (e.g. only OPTION|OPTGROUP in SELECT), maybe inside Html_process_tag()... Committed... -- Cheers Jorge.-

Aug. 25, 2008

patch: make prefs.c and dillorc2 consistent

by jcid＠dillo.org

On Sat, Aug 23, 2008 at 11:30:42PM +0000, corvid wrote: > Jorge wrote: > > BTW, my preference is allow_white_bg=NO, but left it as is > > (YES), waiting for your opinions. > > I had set it to YES because it seemed less surprising for the > people who aren't like me and don't page through dotfiles > when trying software. Yes, that's why I also chose YES in the dillorc. Now, it would be funny if everybody changes it to NO. :-) > In other news, I was just starting to play with the > mangleme fuzzer that Justus mentioned some months back. > It has quickly shown that something is wrong with html->Stash > (e.g. *** glibc detected *** double free or corruption (!prev): 0x08204d28 ***), > but I haven't looked into the problem yet. Oh, I missed that email. Where's the fuzzer? -- Cheers Jorge.-

Aug. 25, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Tue, Aug 19, 2008 at 08:22:54PM +0000, corvid wrote: > > The key is to be informative and that page construction > > and updating is a breeze to do. > > > > > Is it officially obsolete, or should parts of Current Plans > > > migrate over there eventually? > > > > I agree that "current plans" fits the goal better. If you can > > think of a _simple_ way to make it better, go ahead. > > > > This is, in principle I agree that removing the achieved goals > > link, and favouring "Current Plans" improves the site. Now, if we > > find a simple way to keep "Current Plans" up to date and not > > bloated, better. > > I haven't been able to think of anything good... in order to > at least have something, though, how about if I add a link like > "Goals reached since last update" to the bottom of achieved goals, > pointing to current plans? > (where they get migrated over hopefully whenever a release is made, > or at least when they are so old that they can no longer be ignored...) ... or we may switch to this scheme: [Current Plans] // as it is [Changelog Highlights] // for last release [Changelog] // full changelog This looks simple to maintain and understand. (removing achieved goals). -- Cheers Jorge.-

Aug. 25, 2008

Problem compiling on FreeBSD

by jcid＠dillo.org

On Mon, Aug 25, 2008 at 05:12:13PM +0200, Christopher Illies wrote: > On Mon, Aug 25, 2008 at 10:08:53AM -0400, Jorge Arellano Cid wrote: > > > In file included from fltkflatview.hh:9, > > > from fltkflatview.cc:23: > > > fltkviewbase.hh:25: error: 'time_t' does not name a type > > > fltkviewbase.hh:26: error: 'time_t' does not name a type > > > *** Error code 1 > > > > Please try adding: > > > > #include <sys/time.h> > > > > in line 5 of fltkviewbase.hh, and tell us how it goes. > > Thank you, it compiles and works fine now. Good! Committed to CVS. -- Cheers Jorge.-

Aug. 25, 2008

Linksys NSLU2 ARM XScale success report [FWD: Dillo f15 Compatibility List dillo2]

by corvid＠lavabit.com

Holger Paradies wrote: > Hello > succesfully compiled and running dillo2 > cvs20080825 > -build_triplet = armv5tel-unknown-linux-gnu > on linksys-nslu2 266MHZ 32MB RAM > (native build) > debian-lenny_arm gcc version 4.3.1 (Debian 4.3.1-2) > kernel 2.6.25-2-ixp4xx > > and running via ssh -X > > > also success on Debian-Etch x86 > > Greetings Holger

Aug. 25, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

I wrote: > I want to get the status of everything in order to update > http://www.dillo.org/Compatibility.html for dillo2. Updated yesterday after digging through the list archives to supply references showing that it at least worked at some particular date in the past for various systems -- and now here we learn today that FreeBSD wasn't compiling quite cleanly. I wonder whether we could get someone for each system who would have the responsibility (or, let's say "_glory_" :) of responding to "Hey, we changed [some configuration stuff] in the latest CVS. Does it work fine on your system?" messages.

Aug. 25, 2008

Problem compiling on FreeBSD

by christopher.illies＠ki.se

On Mon, Aug 25, 2008 at 10:08:53AM -0400, Jorge Arellano Cid wrote: > > In file included from fltkflatview.hh:9, > > from fltkflatview.cc:23: > > fltkviewbase.hh:25: error: 'time_t' does not name a type > > fltkviewbase.hh:26: error: 'time_t' does not name a type > > *** Error code 1 > > Please try adding: > > #include <sys/time.h> > > in line 5 of fltkviewbase.hh, and tell us how it goes. Thank you, it compiles and works fine now. Christopher

Aug. 25, 2008

Problem compiling on FreeBSD

by jcid＠dillo.org

Hi, On Mon, Aug 25, 2008 at 03:20:46PM +0200, Christopher Illies wrote: > Hi, > > on FreeBSD-7.0-STABLE, fltk-2.0.r6149 from ports I get the following > error while compiling the newest dillo from CVS: > > > cd dw2-cur; ./autogen.sh && ./configure && make > aclocal found > autoheader found > autoconf found > automake found > [Checks passed] > Generating... > /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE > /usr/local/share/aclocal/audiofile.m4:12: run info '(automake)Extending aclocal' > /usr/local/share/aclocal/audiofile.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal > autoheader-2.62: error: AC_CONFIG_HEADERS not found in configure.in > checking build system type... i386-unknown-freebsd7.0 We don't have a conf.h.in file there so I assume the "AC_CONFIG_HEADERS not found" error is not fatal. > > [...] > > g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" > -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 > -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. > -I/usr/local/include -I/usr/local/include/freetype2 > -I/usr/local/include -O2 -fno-strict-aliasing -pipe > -I/usr/local/include -Wno-non-virtual-dtor -g -O2 -D_REENTRANT > -D_THREAD_SAFE -Wall -MT libDw_fltk_a-fltkflatview.o -MD -MP -MF > .deps/libDw_fltk_a-fltkflatview.Tpo -c -o libDw_fltk_a-fltkflatview.o > `test -f 'fltkflatview.cc' || echo './'`fltkflatview.cc > In file included from fltkflatview.hh:9, > from fltkflatview.cc:23: > fltkviewbase.hh:25: error: 'time_t' does not name a type > fltkviewbase.hh:26: error: 'time_t' does not name a type > *** Error code 1 Please try adding: #include <sys/time.h> in line 5 of fltkviewbase.hh, and tell us how it goes. -- Cheers Jorge.-

Aug. 25, 2008

Problem compiling on FreeBSD

by christopher.illies＠ki.se

Hi, on FreeBSD-7.0-STABLE, fltk-2.0.r6149 from ports I get the following error while compiling the newest dillo from CVS: > cd dw2-cur; ./autogen.sh && ./configure && make aclocal found autoheader found autoconf found automake found [Checks passed] Generating... /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/local/share/aclocal/audiofile.m4:12: run info '(automake)Extending aclocal' /usr/local/share/aclocal/audiofile.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal autoheader-2.62: error: AC_CONFIG_HEADERS not found in configure.in checking build system type... i386-unknown-freebsd7.0 [...] g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -O2 -fno-strict-aliasing -pipe -I/usr/local/include -Wno-non-virtual-dtor -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -MT libDw_fltk_a-fltkflatview.o -MD -MP -MF .deps/libDw_fltk_a-fltkflatview.Tpo -c -o libDw_fltk_a-fltkflatview.o `test -f 'fltkflatview.cc' || echo './'`fltkflatview.cc In file included from fltkflatview.hh:9, from fltkflatview.cc:23: fltkviewbase.hh:25: error: 'time_t' does not name a type fltkviewbase.hh:26: error: 'time_t' does not name a type *** Error code 1 Stop in /home/chris/Storage/Programming/dillo/dw2-cur/dw. *** Error code 1 Stop in /home/chris/Storage/Programming/dillo/dw2-cur. Christopher

Aug. 25, 2008

patch: make prefs.c and dillorc2 consistent

by corvid＠lavabit.com

Jorge wrote: > BTW, my preference is allow_white_bg=NO, but left it as is > (YES), waiting for your opinions. I had set it to YES because it seemed less surprising for the people who aren't like me and don't page through dotfiles when trying software. (My aging screen is dimming and no longer capable of displaying a white background anyway.) In other news, I was just starting to play with the mangleme fuzzer that Justus mentioned some months back. It has quickly shown that something is wrong with html->Stash (e.g. *** glibc detected *** double free or corruption (!prev): 0x08204d28 ***), but I haven't looked into the problem yet.

Aug. 24, 2008

patch: make prefs.c and dillorc2 consistent

by jcid＠dillo.org

Hi, On Thu, Aug 21, 2008 at 02:49:15AM +0000, corvid wrote: > The proposal here is to have everything commented out in the > rc by default, and show what the default settings are so > that people don't have to spend as much time experimenting > when they want to configure their nifty superbrowser. OK. > When resolving inconsistencies, I generally picked the rc setting > when uncommented, and the prefs one otherwise. Figured it would > be a fair approximation of what Jorge might accept... Committed. I also set panel_size=large for function visibility and standard_widget_colors=NO (it looks nicer). BTW, my preference is allow_white_bg=NO, but left it as is (YES), waiting for your opinions. > Also, I remember Jorge once saying that maybe it should be > named dillo2rc instead of dillorc2. I think so too. Done. Please don't forget to rename your rc file: mv ~/.dillo/dillorc2 ~/.dillo/dillo2rc With regard to the menu bar, it was reimplemented using a more ortodox way (MenuBar instead of PopupMenu). It works and looks better now! -- Cheers Jorge.-

Aug. 24, 2008

patch: make prefs.c and dillorc2 consistent

by corvid＠lavabit.com

The proposal here is to have everything commented out in the rc by default, and show what the default settings are so that people don't have to spend as much time experimenting when they want to configure their nifty superbrowser. When resolving inconsistencies, I generally picked the rc setting when uncommented, and the prefs one otherwise. Figured it would be a fair approximation of what Jorge might accept... Also, I remember Jorge once saying that maybe it should be named dillo2rc instead of dillorc2. I think so too.

Aug. 21, 2008

Re: Broken links on www-site

by jcid＠dillo.org

On Tue, Aug 19, 2008 at 07:58:06PM +0300, Henri Salo wrote: > On Tue, Aug 19, 2008 at 12:21:56PM -0400, Jorge Arellano Cid wrote: > > Good, if you want to help us, welcome aboard! > > > > Please give a read to the just updated: > > > > http://www.dillo.org/8years.html > > > > and update the wiki. In case of doubt, just ask. > > > > BTW, corvid is about to patch that page along these lines: > > > > Jorge.- > > I have been lurking around in mailing lists for a while if you haven't > already noticed so I have read that link already. It was written this morning! > I have also tested > some patches, but I didn't have anything to say about those. I don't > actually like Wiki{pedia,media} anymore, but I can do exception for > Dillo-project. :-) > For you information there are users who would like test dillo2 using > snapshots from CVS. Should we make proper builds and guides for them? No. I'd prefer them to test the next release. Once it's made, packages are welcomed. -- Cheers Jorge.-

Aug. 19, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Tue, Aug 19, 2008 at 03:28:33PM +0000, corvid wrote: > Jorge wrote: > > BTW, I just wrote and updated the "8 years" page: > > > > http://www.dillo.org/8years.html > > from the above: > ] Our users will surely enjoy this new release as it will give them the same > ] things they're accustomed plus antialiasing, smaller footprint, less > ] dependencies, better table rendering, bugfixes, improved GUI, ... In brief, > ] a better dillo. > > Surely they will enjoy UTF-8, plus the ability to read text in whatever charset > their native language uses, plus gzip content encoding, plus the ability to > load individual images on demand... :) Sure! Please add it in the page. -- Cheers Jorge.-

Aug. 19, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

Jorge wrote: > BTW, I just wrote and updated the "8 years" page: > > http://www.dillo.org/8years.html from the above: ] Our users will surely enjoy this new release as it will give them the same ] things they're accustomed plus antialiasing, smaller footprint, less ] dependencies, better table rendering, bugfixes, improved GUI, ... In brief, ] a better dillo. Surely they will enjoy UTF-8, plus the ability to read text in whatever charset their native language uses, plus gzip content encoding, plus the ability to load individual images on demand... :)

Aug. 19, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Tue, Aug 19, 2008 at 01:36:34AM +0000, corvid wrote: > All right, I came up with: > > * Dillo is a > <a href='http://www.dillo.org/Compatibility.html'>multi-platform</a> > graphical web browser known for its speed and small size. > * Dillo is written in C and C++. > * Dillo is based on <a href='http://www.fltk.org'>FLTK2</a>, the Fast Light > ToolKit. > * Dillo is free software made available under the terms of the GNU General > Public License. > * Dillo strives to be friendly both to users and developers. > * Dillo helps web authors to comply with web standards by using the > <a href='http://www.dillo.org/help/bug_meter.html'>bug meter</a>. OK. (please state GPL3). BTW, I just wrote and updated the "8 years" page: http://www.dillo.org/8years.html -- Cheers Jorge.-

Aug. 19, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Mon, Aug 18, 2008 at 05:31:57PM +0000, corvid wrote: > Jorge wrote: > > BTW, after the WearLab outage I decided to postpone the > > release for late september or so. It's necessary to update > > the website before the code is released. > > Do you think it's time yet to update the parts of What is Dillo on the > main page that have changed (and rip out the Dillo is frozen), or > should that wait until release is very close? Now that you mention it, I believe making it gradually looks like a good idea. Just stick a note that we're updating the site for the next release (late Sep or early Aug), and let's work on it. -- Cheers Jorge.-

Aug. 18, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

Jorge wrote: > BTW, after the WearLab outage I decided to postpone the > release for late september or so. It's necessary to update > the website before the code is released. Do you think it's time yet to update the parts of What is Dillo on the main page that have changed (and rip out the Dillo is frozen), or should that wait until release is very close?

Aug. 18, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Mon, Aug 18, 2008 at 02:24:21AM +0000, corvid wrote: > I want to get the status of everything in order to update > http://www.dillo.org/Compatibility.html for dillo2. Great. BTW, after the WearLab outage I decided to postpone the release for late september or so. It's necessary to update the website before the code is released. > > Linux x86 - works > DragonFlyBSD - works > > Linux x86-64 - Justus was and is making snapshots, but I don't know whether > he uses them much. I'm using 64bit GNU/Linux on an amd64 and it works flawlessly. > Solaris 10 - Justus reported that it was running, but I believe it was just > a quick test. > OSX - Jorge reports that it works but is currently flaky. Yes. On Aug 28 I'll have access once again to that machine to test Johannes' no-double-buffer suggestion. > *BSD - Some of the mailing list traffic in October was devoted to getting > them working. Presumably it would have been mentioned here if they > had stopped working since, but... > > other - no idea. > > Looking back at what I just wrote, let me clarify that I meant that > dillo2-on-osx is flaky, not that Jorge is flaky :) I hope you're right! ;-) -- Cheers Jorge.-

Aug. 18, 2008

towards a consistent UI

by Johannes.Hofmann＠gmx.de

Hi, -------- Original-Nachricht -------- > Datum: Mon, 11 Aug 2008 12:59:32 -0400 > Von: Jorge Arellano Cid <jcid(a)dillo.org> > An: dillo-dev(a)dillo.org > Betreff: Re: [Dillo-dev] towards a consistent UI > Hi, > > Well here's my opinion on these UI points: > > On Mon, Aug 04, 2008 at 09:50:24PM +0200, Johannes Hofmann wrote: > > Hi, > > > > I really like the way Ctrl-l now just selects the current > > URL in normal mode avoiding a dialog window. > > Me too! > > > In fullscreen mode however, the short switch to normal mode to enter > > the new URL requires a complete redraw of the page contents. > > Also the contents "jumps" down for the time the location bar is > > shown. This can be distracting. > > Find text also causes a redraw. Maybe avoiding the redraw in > both cases is a good solution. Not of high priority unless really > simple to implement. I think the flicker can be avoided, but that won't stop the content from "jumping" in the fullscreen case. > > > Do we really want to kill all uses of dialog windows? We still have > > "Search the Web" anyway. > > No. Some dialog windows are quite OK, and there's no need I can see > to ban them. Agreed > > > Also the location of the "IMG ON/OFF" button seems a bit arbitrary. > > I like it where it is, but agree on that it may find a better place. > Together with the other Panel buttons, my be. > Yes maybe. I will try that when I have time. > > How could a consistent user interface of dillo look like? > > > > Here is my proposal - just to start the discussion: > > > > * Everything is accessible via the menubar and via keyboard > > shortcuts. The shortcuts are shown behind the menu entries. > > Currently the main model is context sensitive popups (right click). > There're some things you can't get from them (e.g. Open File), but > I see no point in duplicating the popup menus from the menu bar. > > About everything being accessible via keyboard shortcuts, I don't > agree. I believe there are simpler ways. For instance if there's a > shortcut for every popup menu entry, there's a need to remember a lot > of shortcut/function pairs. Now if there's a shortcut to popup the > context sensitive menu, and that menu is keyboard operable, IMHO that's > easier to remember/use. > If there's a frequently used operation inside a popup, it may have > its own shortcut. I think the advantage of a menu bar is that it's easily visible, what functionality is available. Advanced users will probabely use shortcuts. But you are right. I forgot about the context menus. The link and image menu only makes sense as a context menu. > > > shortcuts are shown behind the menu entries. > > Agreed. > > > * All shortcuts are configurable. > > Agreed. > > > > > * No more img on/off button. One can use a menubar entry or keyboard > > shortcut instead. > > I prefer the button. It's more visible and gives feedback on its > current status. > Firefox has this functionality somewhere, and a few people know > of it. Ok. > > > * The "Search the Web" button should be just as all the other > > buttons ("Back", "Forw" ...) and be configurable of course. > > Agreed. > With something like: > search_url="<title>,<URL>" in dillorc2, with the first > one being the default for instance. > > > Perhaps a single config option like: > > panel_buttons="back, forw, home, reload, save, stop, book" > > I prefer the boolean way (current model). > I was looking for a way to make the ordering configurable too. > > * The "HTML bugs" button in the status bar is ok. > > It shows the bug-state of the current page. > > Agreed! > > > > * "Search the Web" opens the start page of the selected search > > engine (e.g. google.com) and selects the search text field. > > I'm not sure about that, but it avoids the dialog window and it makes > > clear to which search engine the query is sent. > > The additional page load for the empty search page is only > > required once - then it's cached. > > NO! :-) > > I love avoiding the search page. e.g. with google. > > ...but, yes, I see there may be cases where the native HTML interface > is preferred. Maybe a simple flag can help it: > > search_url="<title>,<URL>[,LoadPage]" > > Thus, with no flag, we get a dialog: > > .------------------------------, > | Search with <title>: | > | [_________________________] | > | | > | [Cancel] [OK] | > '------------------------------' > > and with the "LoadPage" flag, the HTML page. > > This can be implemented quickly! ;-) > Or a plugin, that presents a HTML page with search forms? I'm not sure myself :-) > > > * In fullscreen mode "Ctrl-l" opens a dialog window again. Any > > better solution? > > If the redraw can be avoided, could be, if not, the dialog may be > OK. I haven't used this case too much so I don't *feel* the problem. > Yes, I was also thinking about reintroducing the dialog in this case. Cheers, Johannes -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

Aug. 18, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

I want to get the status of everything in order to update http://www.dillo.org/Compatibility.html for dillo2. Linux x86 - works DragonFlyBSD - works Linux x86-64 - Justus was and is making snapshots, but I don't know whether he uses them much. Solaris 10 - Justus reported that it was running, but I believe it was just a quick test. OSX - Jorge reports that it works but is currently flaky. *BSD - Some of the mailing list traffic in October was devoted to getting them working. Presumably it would have been mentioned here if they had stopped working since, but... other - no idea. Looking back at what I just wrote, let me clarify that I meant that dillo2-on-osx is flaky, not that Jorge is flaky :)

Aug. 18, 2008

Dillo in OSX

by Johannes.Hofmann＠gmx.de

-------- Original-Nachricht -------- > Datum: Thu, 14 Aug 2008 15:23:08 -0400 > Von: Jorge Arellano Cid <jcid(a)dillo.org> > An: dillo-dev(a)dillo.org > Betreff: Re: [Dillo-dev] Dillo in OSX > On Thu, Aug 14, 2008 at 04:59:30PM +0000, corvid wrote: > > I just remembered the bit in png.c that goes: > > > > /* Get and set gamma information. Beware: gamma correction 2.2 will > > only work on PC's. todo: select screen gamma correction for other > > platforms. */ > > if (png_get_gAMA(png_ptr, info_ptr, &gamma)) > > png_set_gamma(png_ptr, 2.2, gamma); > > > > Does that still need fixing up for OSX nowadays? > > I didn't notice anything strange when testing dillo2 native in OSX. > Images looked quite normal. Has anyone else tried it? > > BTW, the GUI under OSX has quite a lot of glitches. Mainly > related with canvas refresh calls being lost, selection being really > weird and the "canvas" area stepping a bit over the button panel. You may try with double buffering disabled. If I remember correctly, there is still an unresolved OSX issue in the fltk code used for double buffering. Cheers, Johannes -- Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine f?r Alle: http://www.gmx.net/de/go/messenger03

Aug. 15, 2008

Please help me on this...

by massimo.cesaro＠gmail.com

Hi Jorge, the main source of attraction for Dillo in my case was software efficiency. Actually even more is the suitability to embedded systems. I believe that Dillo could be *the* default browser for a lot of consumer electronics devices as well as mobile internet devices. Finding out the correct mix of featues with a small footprint and a fast execution speed is the real challenge for Dillo; a challenge that could bring this project on the spot light of many embedded developers. My 2 cents. Massimo On Thu, Jul 3, 2008 at 10:19 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi there, > > Looking to a future dillo2 release for the public, I was > wondering about the main drive behind dillo2. > > I mean, in this years of Facebook, WebKit, Flash, propietary > video codecs, etc. what's the main point behind dillo2? > > From the objectives: > > 1.- The democratization of internet information access. > 2.- Personal security and privacy. > 3.- High software efficiency. > > The first one is interesting to analyze along the lines that > dillo allows to search for tons of information spread through the > Internet using low HW requirements and low bandwidth as a dialup. > This is reassuring as dillo efectively enables information > access to any person under such constraints. > > The second one is partly attained by not writing to HD and by a > non-existent scripting support. > > The third one is the one to brag about. ;-) > > > Since some time, the thought that enabling dillo2 as a help > browser could also bring local information (i.e. in HD) closer to > the user came as a powerful one. Having an app. that pops-up in a > second and that's quick, responsive and easy to use is certainly > a strong drive for a person in search of information (that's why > I'd like to see it inside Debian as a help system). > > In the near future, I'd like to have CSS and proper floating > text rendering (DIV element), plus an API as a help browser. > > > There're countries where paying Universitary studies is the > state's burden. If a citizen doesn't want to study there, it's a > choice. I think the same may happen with dillo, once people know > about it, they can choose to use it or not. > > While thinking about it, these comments surprised me: > > "Slashdot | What Do You Want On Future Browsers?" > http://tech.slashdot.org/article.pl?sid=08/06/30/1845201 > > (yes, give them a read!) > > (They're talking from a full featured Firefox basis. I > don't know how may of them would like to use something like > dillo) > > > Behind a project like ours, there're two communities: > developers and users. The main factor to push forward the project > is developers and their motivations (in a commercial environment > what pushes the development is the money invested and the profit > margins/strategy sought). > > That's why I'm asking you to help me with your views, needs > visions on the future of dillo2 these days. > > With regard to the user community, I'd love to have some > feedback from them, but I guess we need to release dillo2 first! > > :-) > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- - Is there anything I can do? - Computer says "no".

Aug. 14, 2008

Dillo in OSX

by jcid＠dillo.org

On Thu, Aug 14, 2008 at 04:59:30PM +0000, corvid wrote: > I just remembered the bit in png.c that goes: > > /* Get and set gamma information. Beware: gamma correction 2.2 will > only work on PC's. todo: select screen gamma correction for other > platforms. */ > if (png_get_gAMA(png_ptr, info_ptr, &gamma)) > png_set_gamma(png_ptr, 2.2, gamma); > > Does that still need fixing up for OSX nowadays? I didn't notice anything strange when testing dillo2 native in OSX. Images looked quite normal. Has anyone else tried it? BTW, the GUI under OSX has quite a lot of glitches. Mainly related with canvas refresh calls being lost, selection being really weird and the "canvas" area stepping a bit over the button panel. -- Cheers Jorge.-

Aug. 14, 2008